51
Tutoriais Linux 1. Configurando IP fixo.................................2 2.Configurando Squid....................................3 3.Configurando servidor DHCP............................24 4.Configurando Samba....................................27 5. Configurando um servidor VPN.........................43

Tutoriais Linux

Embed Size (px)

Citation preview

Page 1: Tutoriais Linux

Tutoriais Linux

1. Configurando IP fixo.....................................................................................2

2.Configurando Squid......................................................................................3

3.Configurando servidor DHCP........................................................................24

4.Configurando Samba....................................................................................27

5. Configurando um servidor VPN....................................................................43

Page 2: Tutoriais Linux

1 -Configurando o usário root:

criar uma senha para o rootsudo passwd root

2 Configurando endereço IP estático.

Para configurar um endereço estático no servidor seguiremos os passos:

1 - configurar um endereço ip fixo. para isso utilizei o editor nano.

sudo nano /etc/network/interfaces

Troque o texto abaixo....auto eth0iface eth0 inet dhcp.... pelo textoauto eth0iface eth0 inet staticaddress 192.168.1.10netmask 255.255.255.0network 192.168.1.0broadcast 192.168.1.255gateway 192.168.1.1

2 - Especifique os servidores de DNSsudo nano /etc/resolv.conf

nameserver 192.168.1.10nameserver 201.6.0.112nameserver 201.6.0.108

3- Reinicie a rede do servidorsudo /etc/init.d/networking restart

2 -Configurando um servidor proxy com o Squid

O Squid permite compartilhar a conexão entre vários micros, servindo como um intermediário entre eles e a internet. Usar um proxy é diferente de simplesmente compartilhar a conexão diretamente, via NAT. 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.

Squid é composto de um único pacote, por isso a instalação é simples. Instale o pacote "squid" usando o apt-get, yum ou urpmi, como em:# apt-get install squidToda a configuração do Squid é feita em um único arquivo, o "/etc/squid/squid.conf". Caso você esteja usando uma versão antiga do Squid, como a incluída no Debian Woody, por exemplo, o arquivo pode ser o "/etc/squid.conf". Apesar da mudança na localização do arquivo de configuração, as opções descritas aqui vão funcionar sem maiores problemas.O arquivo original, instalado junto com o pacote, é realmente enorme, contém comentários e exemplos para quase todas as opções disponíveis. Ele pode ser uma leitura interessante se você já tem uma boa familiaridade com o Squid e quer aprender mais sobre cada opção, mas, de início, é melhor começar com um arquivo de configuração mais simples, apenas com as opções mais usadas.Em geral, cada distribuição inclui uma ferramenta diferente para a configuração do proxy. Uma das mais usadas é o Webmin, disponível em várias distribuições. A função dessas ferramentas é disponibilizar as opções através de uma interface gráfica e gerar o arquivo de configuração com base nas opções

Page 3: Tutoriais Linux

escolhidas. Em alguns casos, essas ferramentas ajudam bastante, mas, como elas mudam de distribuição para distribuição, acaba sendo mais produtivo aprender a trabalhar direto no arquivo de configuração, que, afinal, não é tão complicado assim. Assim como em outros tópicos do livro, vamos aprender a configurar o Squid "no muque", sem depender de utilitários de configuração.Comece renomeando o arquivo padrão, de forma a conservá-lo para fins de pesquisa:# mv /etc/squid/squid.conf /etc/squid/squid.conf.origEm seguida, crie um novo arquivo "/etc/squid/squid.conf", contendo apenas as quatro linhas abaixo:http_port 3128visible_hostname serveracl all src 0.0.0.0/0.0.0.0http_access allow allEstas linhas são o suficiente para que o Squid "funcione". Como viu, aquele arquivo de configuração gigante tem mais uma função informativa, citando e explicando as centenas de opções disponíveis. Apenas um punhado das opções são realmente necessárias, pois, ao omití-las, o Squid simplesmente utiliza os valores default. É por isso que acaba sendo mais simples começar com um arquivo vazio e ir inserindo apenas as opções que você conhece e deseja alterar.As quatro linhas dizem o seguinte:http_port 3128: A porta onde o servidor Squid vai ficar disponível. A porta 3128 é o default, mas muitos administradores preferem utilizar a porta 8080, que soa mais familiar a muitos usuários.visible_hostname server: O nome do servidor, o mesmo que foi definido na configuração da rede. Ao usar os modelos desse capítulo, não se esqueça de substituir o "servidor" pelo nome correto do seu servidor, como informado pelo comando "hostname".acl all src 0.0.0.0/0.0.0.0 e http_access allow all: Estas duas linhas criam uma acl (uma política de acesso) chamada "all" (todos), incluindo todos os endereços IP possíveis. Ela permite que qualquer um dentro desta lista use o proxy, ou seja, permite que qualquer um use o proxy, sem limitações.Para testar a configuração, reinicie o servidor Squid com o comando:# /etc/init.d/squid restartSe estiver no CentOS, Fedora ou Mandriva, pode utilizar o comando "service", que economiza alguns toques no teclado:# service squid restartNo Slackware, o comando será "/etc/rc.d/rc.squid restart", seguindo a lógica do sistema em colocar os scripts referentes aos serviços na pasta /etc/rc.d/ e inicializá-los automaticamente durante o boot, desde que marcada a permissão de execução.Para testar o proxy, configure um navegador (no próprio servidor) para usar o proxy, através do endereço 127.0.0.1 (o localhost), porta 3128. Se não houver nenhum firewall pelo caminho, você conseguirá acessar o proxy também através dos outros micros da rede local, basta configurar os navegadores para usarem o proxy, fornecendo o endereço do servidor na rede local.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 (a interface eth0 no exemplo) é:iptables -A INPUT -i eth0 -p tcp --dport 3128 -j ACCEPT

Criando uma configuração básica

O problema com o modelo de configuração minimalista que acabamos de ver é que com apenas estas quatro linhas o proxy ficará muito aberto. Se você deixar o servidor proxy ativo no próprio servidor que compartilha a conexão e não houver nenhum firewall ativo, qualquer um na internet poderia usar o seu proxy, o que naturalmente não é desejado. O proxy deve ficar ativo apenas para a rede local.

Vamos gerar, então, um arquivo mais completo, permitindo que apenas os micros da rede local possam usar o proxy e definindo mais algumas políticas de segurança. Neste segundo exemplo já aproveitei algumas linhas do arquivo original, criando regras que permitem o acesso a apenas algumas portas específicas e não mais a qualquer coisa, como na configuração anterior:

http_port 3128visible_hostname servidoracl all src 0.0.0.0/0.0.0.0acl manager proto cache_objectacl localhost src 127.0.0.1/255.255.255.255acl SSL_ports port 443 563acl Safe_ports port 80 # http

Page 4: Tutoriais Linux

acl Safe_ports port 21 # ftpacl Safe_ports port 443 563 # https, snewsacl Safe_ports port 70 # gopheracl Safe_ports port 210 # waisacl Safe_ports port 280 # http-mgmtacl Safe_ports port 488 # gss-httpacl Safe_ports port 591 # filemakeracl Safe_ports port 777 # multiling httpacl Safe_ports port 901 # swatacl Safe_ports port 1025-65535 # portas altasacl purge method PURGEacl CONNECT method CONNECThttp_access allow manager localhosthttp_access deny managerhttp_access allow purge localhosthttp_access deny purgehttp_access deny !Safe_portshttp_access deny CONNECT !SSL_portsacl redelocal src 192.168.1.0/24http_access allow localhosthttp_access allow redelocalhttp_access deny all

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. Neste exemplo, usei a configuração-modelo indicada na documentação do Squid, que prevê o uso de diversos protocolos conhecidos e também o uso de portas altas, acima da 1024. Ela é tão extensa porque cada porta é especificada em uma linha diferente. Podemos simplificar isso agrupando as portas na mesma linha, o que resulta em um arquivo de configuração muito menor, mas que faz exatamente a mesma coisa:

http_port 3128visible_hostname servidoracl all src 0.0.0.0/0.0.0.0acl manager proto cache_objectacl localhost src 127.0.0.1/255.255.255.255acl SSL_ports port 443 563acl Safe_ports port 21 80 443 563 70 210 280 488 59 777 901 1025-65535acl purge method PURGEacl CONNECT method CONNECThttp_access allow manager localhosthttp_access deny managerhttp_access allow purge localhosthttp_access deny purgehttp_access deny !Safe_portshttp_access deny CONNECT !SSL_portsacl redelocal src 192.168.1.0/24http_access allow localhosthttp_access allow redelocalhttp_access deny all

Veja que em ambos os exemplos adicionei duas novas acl's. A acl "localhost" contém o endereço 127.0.0.1, que você utiliza ao usar o proxy localmente (ao navegar usando o próprio ), e a acl "rede local", que inclui os demais micros da rede local. Substitua o "192.168.1.0/24" pela faixa de endereços IP e a máscara de sub-rede usada na sua rede local (o 24 equivale à mascara 255.255.255.0).

Depois de criadas as duas políticas de acesso, vão duas linhas no final do arquivo que especificam que os micros que se enquadrarem nelas poderão usar o proxy:

http_access allow localhosthttp_access allow redelocal

Page 5: Tutoriais Linux

Lembra-se da acl "all", que contém todo mundo? Vamos usá-la para especificar que os clientes que não se enquadrarem nas duas regras acima (ou seja, clientes não-autorizados, vindos da Internet) não poderão usar o proxy:

http_access deny all

Esta linha deve ir no final do arquivo, depois das outras duas. A ordem é importante, pois o Squid interpreta as regras na ordem em que são colocadas no arquivo. Se você permite que o micro X acesse o proxy, ele acessa, mesmo que uma regra mais abaixo diga que não.

Se você adicionasse algo como:acl redelocal src 192.168.1.0/24http_access allow redelocalhttp_access deny redelocal

... os micros da rede local continuariam acessando, pois a regra que permite vem antes da que proíbe.

Existem alguns casos de sites que não funcionam bem quando acessados através de proxies, um exemplo comum é o "Conectividade Social", da Caixa. Normalmente nesses casos o problema está em algum recurso fora do padrão usado pelo sistema do site e não no proxy propriamente dito, mas, de qualquer forma, você pode solucionar o problema de forma muito simples orientando o proxy a repassar as requisições destinadas ao site diretamente.

Para isso, adicionamos uma ACL na configuração, especificando a URL do site e usando a opção "always_direct":

acl site dstdomain siteproblematico.comalways_direct allow site

Esta regra deve vir antes da regra que libera os acessos provenientes da rede local, como em:acl site dstdomain siteproblematico.comalways_direct allow siteacl redelocal src 192.168.1.0/24http_access allow localhosthttp_access allow redelocalhttp_access deny all

Depois de configurar o arquivo, não se esqueça de reiniciar o serviço para que a configuração entre em vigor:# /etc/init.d/squid restart

Nesse ponto o seu proxy já está completamente funcional. Você pode começar a configurar os navegadores nos PCs da rede local para utilizá-lo e acompanhar o desempenho da rede. Agora que já vimos o arroz com feijão, vamos aos detalhes mais avançados da configuração:Configurando o cache de páginas e arquivos

Uma das configurações mais importantes com relação ao desempenho do proxy e à otimização do tráfego da rede é a configuração dos caches, onde o Squid guarda as páginas e arquivos já acessados de forma a fornecê-los rapidamente quando solicitados novamente. O Squid trabalha com dois tipos de cache:

1- Cache rápido, feito usando parte da memória RAM do ;2- Cache um pouco mais lento porém maior, feito no HD.

O cache na memória RAM é ideal para armazenar arquivos pequenos, como páginas html e imagens, que serão entregues instantaneamente para os clientes. O cache no HD é usado para armazenar arquivos maiores, como downloads, arquivos do Windows Update e pacotes baixados via apt-get.

O cache na memória RAM é sempre relativamente pequeno, já que o volume de memória RAM no é sempre muito menor do que o espaço em disco. O cache no HD pode ser mais generoso, afinal a idéia é que ele guarde todo tipo de arquivos, principalmente os downloads grandes, que demoram para serem baixados.

A configuração do cache é feita adicionando mais algumas linhas no arquivo de configuração:

Page 6: Tutoriais Linux

1- A configuração da quantidade de memória RAM dedicada ao cache é feita adicionando a opção "cache_mem", que contém a quantidade de memória que será dedicada ao cache. Para reservar 64 MB, por exemplo, a linha ficaria:

cache_mem 64 MB

Como regra geral, você pode reservar 32 ou 64 MB para o cache em um não dedicado, que atende a apenas alguns micros (como o de uma pequena rede local) e até 1/3 da memória RAM total em um proxy dedicado, que atende a um volume maior de usuários (veja mais detalhes a seguir). Em um com 1 GB de RAM, por exemplo, você poderia reservar até 350 MB para o cache na memória.2- Logo depois vai a opção "maximum_object_size_in_memory", que determina o tamanho máximo dos arquivos que serão guardados no cache feito na memória RAM (o resto vai para o cache feito no HD). O cache na memória é muito mais rápido, mas como a quantidade de RAM é muito limitada, é melhor deixá-la disponível para páginas web, figuras e arquivos pequenos em geral. Para que o cache na memória armazene arquivos de até 64 KB, por exemplo, adicione a linha:

maximum_object_size_in_memory 64 KB3- Em seguida vem a configuração do cache em disco, que armazenará o grosso dos arquivos. Por default, o máximo são downloads de até 16 MB e o mínimo é zero, o que faz com que mesmo imagens e arquivos pequenos sejam armazenados no cache. Quase sempre é mais rápido ler a partir do cache do que baixar de novo da web, mesmo que o arquivo seja pequeno.

Se você faz download de arquivos grandes com freqüência e deseja que eles fiquem armazenados no cache, aumente o valor da opção "maximum_object_size". Isso é especialmente útil para quem precisa baixar muitos arquivos através do apt-get ou Windows Update em muitos micros da rede. Se você quiser que o cache armazene arquivos de até 512 MB, por exemplo, as linhas ficariam:

maximum_object_size 512 MBminimum_object_size 0 KB

Você pode definir ainda a percentagem 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 para um número abaixo de 90%:

cache_swap_low 90cache_swap_high 95

4- Depois vem a opção "cache_dir", que é composta por quatro valores. O primeiro, (/var/spool/squid) indica a pasta onde o Squid armazena os arquivos do cache, enquanto o segundo (2048) indica a quantidade de espaço no HD (em MB) que será usada para o cache. Aumente o valor se você tem muito espaço no HD do e quer que o Squid guarde os downloads por muito tempo.Continuando, os números 16 e 256 indicam a quantidade de subpastas que serão criadas dentro do diretório. Por padrão, temos 16 pastas com 256 subpastas cada uma. O número "ideal" de pastas e subpastas para um melhor desempenho varia de acordo com o sistema de arquivos usado, mas esta configuração padrão é adequada para a maioria das situações. Combinando as quatro opções, a linha ficaria:

cache_dir ufs /var/spool/squid 2048 16 256

Assim como na maioria das opções do Squid, se a linha "cache_dir" for omitida, é usada a configuração default para a opção, que é usar o diretório "/var/spool/squid" e fazer um cache em disco de 100 MB.5- Você pode definir ainda o arquivo onde são guardados os logs de acesso do Squid. Por padrão, o Squid guarda o log de acesso no arquivo "/var/log/squid/access.log". Este arquivo é usado pelo Sarg para gerar as páginas com as estatísticas de acesso:

cache_access_log /var/log/squid/access.log

Mais uma configuração que você pode querer alterar é o padrão de atualização do cache. Estas três linhas precisam sempre ser usadas em conjunto, ou seja, você pode alterá-las, mas sempre as três precisam estar presentes no arquivo. Eliminando uma, o Squid ignora as outras duas e usa o default.

Os números indicam o intervalo (em minutos) que o Squid irá aguardar antes de verificar se um item do cache (uma página, por exemplo) foi atualizado, para cada um dos três protocolos. O primeiro número (o 15) indica que o Squid verificará (a cada acesso) se as páginas e arquivos com mais de 15 minutos foram atualizados. Ele faz uma verificação rápida, checando o tamanho do arquivo e, se o arquivo não mudou, ele continua fornecendo aos clientes o arquivo que está no cache, economizando banda da conexão

Page 7: Tutoriais Linux

O terceiro número (o 2280, equivalente a dois dias) indica o tempo máximo, depois do qual o objeto é sempre verificado. Além do http e ftp, o Squid suporta o protocolo gopher, que era muito usado nos primórdios da internet para localizar documentos de texto, mas perdeu a relevância hoje em dia:

refresh_pattern ^ftp: 15 20% 2280refresh_pattern ^gopher: 15 0% 2280refresh_pattern . 15 20% 2280

Depois de adicionar todas estas configurações, o nosso arquivo de configuração já ficará bem maior:http_port 3128visible_hostname servidorcache_mem 64 MBmaximum_object_size_in_memory 64 KBmaximum_object_size 512 MBminimum_object_size 0 KBcache_swap_low 90cache_swap_high 95cache_dir ufs /var/spool/squid 2048 16 256cache_access_log /var/log/squid/access.logrefresh_pattern ^ftp: 15 20% 2280refresh_pattern ^gopher: 15 0% 2280refresh_pattern . 15 20% 2280acl all src 0.0.0.0/0.0.0.0acl manager proto cache_objectacl localhost src 127.0.0.1/255.255.255.255acl SSL_ports port 443 563acl Safe_ports port 21 80 443 563 70 210 280 488 59 777 901 1025-65535acl purge method PURGEacl CONNECT method CONNECThttp_access allow manager localhosthttp_access deny managerhttp_access allow purge localhosthttp_access deny purgehttp_access deny !Safe_portshttp_access deny CONNECT !SSL_portsacl redelocal src 192.168.1.0/24http_access allow localhosthttp_access allow redelocalhttp_access deny all

Aqui já temos uma configuração mais completa, incluindo um conjunto de regras de segurança (para que o proxy seja usado apenas a partir da rede local) e a configuração do cache. Esta é uma configuração adequada para uso em uma rede doméstica ou em um pequeno escritório.A acl "Safe_ports", alimentada com um conjunto de portas (80, 21 e outras) é usada para restringir as portas de saída do proxy, evitando, por exemplo, que ele seja usado para enviar e-mails (porta 25). Isso evita um conjunto de abusos comuns e é uma configuração importante em qualquer que precise ser configurado de forma minimamente segura. Naturalmente, você pode adicionar outras portas à lista, conforme necessário.

Em uma rede maior, você provavelmente iria querer adicionar algumas limitações de acesso, limitando o acesso a algumas páginas, criando um sistema de autenticação ou limitando o uso com base no horário, entre outras possibilidades. Vamos a elas.Bloqueando por domínios ou palavras

O Squid permite bloquear sites indesejados de forma bastante simples usando o parâmetro "dstdomain". Ele permite que você crie acl's contendo endereços de sites que devem ser bloqueados (ou permitidos). Isso é feito em duas etapas. Primeiro você cria a acl, especificando os endereços e, em seguida, usa o parâmetro "http_access" para bloquear ou liberar o acesso a eles. Veja um exemplo:

acl bloqueados dstdomain orkut.com playboy.abril.com.brhttp_access deny bloqueados

Page 8: Tutoriais Linux

Aqui eu criei uma acl chamada "bloqueados", que contém os endereços "orkut.com" e "playboy.abril.com.br" e em seguida usei o parâmetro "http_access deny" para bloquear o acesso a eles. Você pode incluir diversas acls diferentes dentro da configuração do Squid, desde que use um nome diferente para cada uma. De certa forma, elas são similares às variáveis, que usamos ao programar em qualquer linguagem.

Ao aplicar a regra, o Squid faz a resolução do domínio e passa a bloquear todas sub-páginas que estiverem hospedadas dentro dele. Existe uma ressalva: muitos sites podem ser acessados tanto com o "www" quanto sem. Se os dois estiverem hospedados em es diferentes, o Squid considerará que tratam-se de dois sites diferentes, de forma que ao bloquear apenas o "www.orkut.com" os usuários ainda conseguirão acessar o site através do "orkut.com" e vice-versa. Nesses casos, para bloquear ambos, é preciso incluir as duas possibilidades dentro da regra, como em:

acl bloqueados dstdomain orkut.com www.orkut.com playboy.abril.com.br http_access deny bloqueados

Você pode incluir quantos domínios quiser dentro da acl, basta separá-los por espaço e deixar tudo na mesma linha. Se a regra começar a ficar muito grande, você tem a opção de transferir as entradas para um arquivo. Nesse caso, crie um arquivo de texto simples, com todos os domínios desejados (um por linha), como em:

orkut.com www.orkut.com playboy.abril.com.brwww.myspace.com

... e use a regra abaixo na configuração do Squid para que ele seja processado e os domínios sejam incluídos na acl. No exemplo, estou usando o arquivo "/etc/squid/bloqueados":

acl bloqueados url_regex -i "/etc/squid/bloqueados"http_access deny bloqueados

Naturalmente, não seria viável tentar bloquear manualmente todos os sites pornográficos, chats, comunidades online, e todos os outros tipos de sites que não são úteis em um ambiente de trabalho. A idéia seria logar os acessos (com a ajuda do Sarg, que veremos mais adiante) e bloquear os sites mais acessados, conforme tomar conhecimento deles. É sempre uma corrida de gato e rato, mas, em se tratando de pessoas adultas, não há nada que uma boa conversa com o chefe não possa resolver. ;)

De qualquer forma, em alguns ambientes pode ser mais fácil bloquear inicialmente o acesso a todos os sites e ir abrindo o acesso a apenas alguns sites específicos, conforme a necessidade. Neste caso, invertemos a lógica da regra. Criamos um arquivo com sites permitidos, adicionamos a regra que permite o acesso a eles e em seguida bloqueamos o acesso a todos os demais, como neste exemplo:

acl permitidos url_regex -i "/etc/squid/permitidos"http_access allow permitidoshttp_access deny all

Nas versões recentes do Squid, ao bloquear um domínio é automaticamente bloqueado também o endereço IP do correspondente. Isso evita que os usuários da rede consigam burlar o proxy, acessando os sites diretamente pelo IP. De qualquer forma, você pode criar diretamente regras que bloqueiem determinados endereços IP, o que é útil em casos de es sem domínio registrado, ou que respondam por vários domínios. Nesse caso, a regra ficaria:

acl ips-bloqueados dst 200.234.21.23 200.212.15.45http_access deny ips-bloqueados

Você pode descobrir rapidamente o endereço IP de um determinado domínio usando o comando "host", como em:$ host google.com

google.com A 72.14.207.99google.com A 64.233.187.99google.com A 64.233.167.99

Depois de adicionar as novas regras, nosso arquivo de configuração ficaria assim:

Page 9: Tutoriais Linux

http_port 3128visible_hostname servidorerror_directory /usr/share/squid/errors/Portuguese/cache_mem 64 MBmaximum_object_size_in_memory 64 KBmaximum_object_size 512 MBminimum_object_size 0 KBcache_swap_low 90cache_swap_high 95cache_dir ufs /var/spool/squid 2048 16 256cache_access_log /var/log/squid/access.logrefresh_pattern ^ftp: 15 20% 2280refresh_pattern ^gopher: 15 0% 2280refresh_pattern . 15 20% 2280acl all src 0.0.0.0/0.0.0.0acl manager proto cache_objectacl localhost src 127.0.0.1/255.255.255.255acl SSL_ports port 443 563acl Safe_ports port 21 80 443 563 70 210 280 488 59 777 901 1025-65535acl purge method PURGEacl CONNECT method CONNECThttp_access allow manager localhosthttp_access deny managerhttp_access allow purge localhosthttp_access deny purgehttp_access deny !Safe_portshttp_access deny CONNECT !SSL_portsacl bloqueados url_regex -i "/etc/squid/bloqueados"http_access deny bloqueadosacl redelocal src 192.168.1.0/24http_access allow localhosthttp_access allow redelocalhttp_access deny all

Veja que coloquei as duas regras antes do "http_access allow redelocal", que abre tudo para a rede local. Como o Squid processa as regras seqüencialmente, as páginas que forem bloqueadas pela acl "bloqueados" não chegam a passar pela regra que autoriza os acessos provenientes da rede local.

Uma segunda possibilidade é usar o parâmetro "dstdom_regex", que permite bloquear sites de uma forma mais geral, com base em palavras incluídas na URL de acesso. Você pode bloquear todas as páginas cujo endereço inclua a palavra "sexo" ou "orkut", por exemplo. Note que, ao usar esta regra, o Squid verifica a existência das palavras apenas na URL do site e não no conteúdo da página. Para criar filtros baseados no conteúdo, você pode utilizar o DansGuardian, que veremos mais adiante.

Crie mais um arquivo de texto, contendo as palavras que devem ser bloqueadas, uma por linha, como em:orkutxxxsexoteenswarez

... e adicione a regra abaixo, contendo a localização do arquivo:acl palavrasproibidas dstdom_regex "/etc/squid/palavrasproibidas"http_access deny palavrasproibidas

O uso desta regra é um pouco mais problemático, pois bloqueará todas páginas que contenham qualquer uma das palavras listadas na URL. Esta opção sempre levará a alguns falsos positivos e por isso deve ser usada com mais cuidado.

Page 10: Tutoriais Linux

Uma vantagem é que ela permite bloquear facilmente páginas dinâmicas, onde a palavra é passada como parâmetro da URL. Um exemplo é o Orkut, onde, depois da transferência para o Google, os domínios principais passaram a encaminhar para URLs dinâmicas dentro do domínio do Google, como em:

https://www.google.com/accounts/ServiceLogin?service=orkut&continue=http%3A%2F%2Fwww.orkut.com%2FRedirLogin.aspx%3Fmsg%3D0%26page%3Dhttp%253A%252F%252Fwww.orkut.com%252FHome.aspx&hl=pt-BR&rm=false&passive=true

Você não poderia simplesmente bloquear o domínio "google.com" usando uma regra url_regex, mas poderia muito bem usar o dstdom_regex para bloquear a palavra "orkut" e assim bloquear o acesso ao site sem bloquear o acesso a outros serviços do Google.

Não existe problema em combinar o bloqueio de domínios e de palavras dentro da URL, você pode lançar mão de uma combinação das duas coisas, de acordo com a situação. Para isso, basta usar as duas regras simultaneamente, como em:

acl bloqueados url_regex -i "/etc/squid/bloqueados"http_access deny bloqueadosacl palavrasproibidas dstdom_regex "/etc/squid/palavrasproibidas"http_access deny palavrasproibidasacl redelocal src 192.168.1.0/24http_access allow localhosthttp_access allow redelocalhttp_access deny all

Por padrão, as mensagens de erro aparecerem em inglês. No nosso caso elas estão aparecendo em português devido à linha "error_directory /usr/share/squid/errors/Portuguese/" que incluí no modelo de configuração anterior.Você pode personalizar as páginas de erro editando os arquivos dentro da pasta "/usr/share/squid/errors/Portuguese" ou "/usr/share/squid/errors/English" (de acordo com a língua definida na configuração). A pasta contêm várias páginas html, uma para cada tipo de erro indicado.Bloqueando por horário

As regras a seguir fazem com que o proxy aceite ou recuse conexões feitas dentro de determinados horários. Você pode definir regras para períodos específicos e combiná-las para bloquear todos os horários em que você não quer que o proxy seja usado ou vice-versa. Para que o proxy bloqueie acessos feitos entre meia-noite e 6:00 da manhã e no horário de almoço, por exemplo, você usaria as regras:

acl madrugada time 00:00-06:00http_access deny madrugadaacl almoco time 12:00-14:00http_access deny almoco

Estas regras iriam, novamente, antes da regra "http_access allow redelocal" no arquivo de configuração.

Agora, imagine que você quer fazer diferente. Ao invés de bloquear o acesso na hora de almoço, você quer deixar o proxy aberto, para que aqueles que queiram acessar o Orkut ou acessar os e-mails possam fazer isso fora do horário de trabalho. Neste caso, você usaria uma regra como:

acl almoco time 12:00-14:00http_access allow almoco

Esta regra entraria no arquivo de configuração antes das regras "http_access deny bloqueados" e outras restrições. Assim, os acessos que forem aceitos pela regra do almoço não passarão pelas regras que fazem o bloqueio, como em:

acl almoco time 12:00-14:00http_access allow almocoacl bloqueados url_regex -i "/etc/squid/bloqueados"http_access deny bloqueadosacl extban url_regex -i "/etc/squid/extban"http_access deny extbanacl redelocal src 192.168.1.0/24http_access allow localhosthttp_access allow redelocalhttp_access deny all

Page 11: Tutoriais Linux

Você pode também combinar o bloqueio de palavras ou domínio 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, a regra seria:

acl almoco time 12:00-14:00acl orkut dstdomain orkut.com www.orkut.comhttp_access allow orkut almocohttp_access deny orkut

Fazendo isso, o Squid entende que os endereços incluídos dentro da acl "orkut" devem ser permitidos, mas apenas dentro do horário especificado na acl "almoco". Em seguida é incluída mais uma regra, que bloqueia o acesso ao site em outros horários.

Gerenciando o uso da banda

O Squid oferece uma forma simples de limitar o uso da banda disponível e definir o quanto cada usuário pode usar (mantendo parte do link livre para os demais), utilizando um recurso chamado "delay pools". Imagine, por exemplo, que você tem um link de 1 megabit 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.

Você pode evitar isso limitando a banda que cada usuário pode usar e a banda total, que todos os usuários somados poderão usar simultaneamente. É recomendável, neste caso, que o proxy (que combina todos os acessos via http) consuma um pouco menos que o total de banda disponível, de forma a sempre deixar um pouco reservado para outros protocolos.

Um link de 1 megabit (1024 kbits) corresponde a 131.072 bytes por segundo. Nas regras do Squid, sempre usamos bytes, por isso lembre-se de fazer a conversão, dividindo o valor em kbits por 8 e multiplicando por 1024 para ter o valor em bytes.

Podemos, por exemplo, limitar a banda total usada pelo Squid a 114.688 bytes por segundo, deixando 128 kbits do link livres para outros protocolos e limitar cada usuário a no máximo 16.384 bytes por segundo, que correspondem a 128 kbits. Nem todos os usuários vão ficar baixando arquivos a todo momento, por isso o valor ideal reservado a cada usuário vai variar muito de acordo com a rede. Você pode acompanhar o uso do link e ir ajustando o valor conforme a utilização.

Neste caso, a parte final do arquivo de configuração ficaria:acl redelocal src 192.168.1.0/24delay_pools 1delay_class 1 2delay_parameters 1 114688/114688 16384/16348delay_access 1 allow redelocalhttp_access allow localhosthttp_access allow redelocalhttp_access deny all

A acl "redelocal" está agora condicionada a três novas regras, que aplicam o uso do limite de banda. O acesso continua sendo permitido, mas agora dentro das condições especificadas na linha "delay_parameters 1 114688/114688 16384/16384", onde vão (respectivamente) os valores com a banda total disponível para o Squid e a banda disponível para cada usuário.

Veja que nessa regra limitamos a banda apenas para a acl "redelocal" e não para o "localhost". Isso significa que você continua conseguindo fazer downloads na velocidade máxima permitida pelo link ao acessar a partir do próprio ; a regra se aplica apenas às estações.

É possível também criar regras de exceção para endereços IP específicos, que poderão fazer downloads sem passar pelo filtro. Nesse caso, criamos uma acl contendo o endereço IP da estação que deve ter o acesso liberado usando o parâmetro "src" e a colocamos antes da regra que limita a velocidade, como em:

acl chefe src 192.168.1.2http_access allow chefe

Page 12: Tutoriais Linux

acl redelocal src 192.168.1.0/24delay_pools 1delay_class 1 2delay_parameters 1 114688/114688 16384/16348delay_access 1 allow redelocalhttp_access allow localhosthttp_access allow redelocalhttp_access deny all

Esta regra de exceção pode der usada também em conjunto com as demais regras de restrição de acesso que vimos anteriormente. Basta que a acl com o IP liberado seja colocada antes das acls com as restrições de acesso, como em:

acl chefe src 192.168.1.2http_access allow chefeacl bloqueados url_regex -i "/etc/squid/bloqueados"http_access deny bloqueadosacl palavrasproibidas dstdom_regex "/etc/squid/palavrasproibidas"http_access deny palavrasproibidasacl redelocal src 192.168.1.0/24http_access allow localhosthttp_access allow redelocalhttp_access deny all

Concluindo, mais um tipo de bloqueio útil em muitas situações é com relação a formatos de arquivos. Você pode querer 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.

Neste caso, você pode usar a regra a seguir, especificando as extensões de arquivo desejadas. Ela utiliza o parâmetro "url_regex" (o mesmo que utilizamos para criar o bloqueio de domínios), dessa vez procurando pelas extensões de arquivos especificadas:

acl extban url_regex -i \.avi \.exe \.mp3 \.torrenthttp_access deny extban

Esta regra aceita também o uso de um arquivo externo, de forma que se a lista começar a ficar muito grande, você pode migrá-la para dentro de um arquivo de texto e especificar sua localização dentro da acl, como em:

acl extban url_regex -i "/etc/squid/extban"http_access deny extban

Dentro do arquivo, você inclui as extensões desejadas (sem esquecer da barra invertida antes do ponto), uma por linha, como em:

\.avi\.exe\.mp3\.torrent

Uma observação é que bloquear arquivos .torrent usando essa regra não impede que os usuários da rede utilizem o bittorrent, mas apenas que baixem os arquivos .torrent para iniciarem o download (o que acaba sendo o suficiente para fazer os usuários menos técnicos desistirem de baixar o arquivo). Para realmente bloquear o download de arquivos via bittorrent, é necessário bloquear diretamente os endereços dos trackers.

Continuando, sempre que fizer alterações na configuração, você pode aplicar as mudanças usando o comando:# /etc/init.d/squid reload

Evite usar o "/etc/init.d/squid restart" em ambientes de produção, pois ele 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 faz com que o

Page 13: Tutoriais Linux

proxy fique vários segundos (ou até minutos, de acordo com o número de clientes conectados a ele) sem responder conexões, fazendo com que o acesso fique fora do ar:# /etc/init.d/squid restart

Restarting Squid HTTP proxy: squid Waiting.....................done.

O parâmetro "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 no serviço, como no caso do Apache.Proxy com autenticação

Você pode adicionar uma camada extra de segurança exigindo autenticação no proxy. Este recurso pode ser usado para controlar quem tem acesso à internet e auditar os acessos em caso de necessidade. Quase todos os navegadores oferecem a opção de salvar a senha, de modo que o usuário precisa digitá-la apenas uma vez a cada sessão:

A forma mais simples de implementar 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 você pode cadastrar e bloquear os usuários rapidamente.Para criar o arquivo de senhas, precisamos do script "htpasswd". Nas distribuições derivadas do Debian ele faz parte do pacote apache2-utils, que você pode instalar via apt-get:# apt-get install apache2-utilsNo CentOS e no Fedora ele faz parte do pacote principal do apache (o pacote "httpd"), que pode ser instalado através do yum.Em seguida, crie o arquivo que será usado para armazenar as senhas, usando o comando "touch" (que simplesmente cria um arquivo de texto vazio):# touch /etc/squid/squid_passwdO próximo passo é cadastrar os logins usando o htpasswd, especificando o arquivo que acabou de criar e o login que será cadastrado, como em:# htpasswd /etc/squid/squid_passwd servidorDepois de terminar de cadastrar os usuários, adicione as linhas que ativam a autenticação no squid.conf:auth_param basic realm Squidauth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/squid_passwdacl autenticados proxy_auth REQUIREDhttp_access allow autenticadosO "auth_param basic realm Squid" indica o nome do , da forma como ele aparecerá na janela de autenticação dos clientes; esta é na verdade uma opção meramente estética. O "/usr/lib/squid/ncsa_auth" é a localização da biblioteca responsável pela autenticação. Eventualmente, ela pode estar em uma pasta diferente dentro da distribuição que estiver usando; nesse caso, use o comando "locate" ou a busca do sistema para encontrar o arquivo e altere a linha indicando a localização correta. Finalmente, o "/etc/squid/squid_passwd" indica a localização do arquivo de senhas que criamos no passo anterior.Estas quatro linhas criam uma acl chamada "autenticados" (poderia ser outro nome), que contém os usuários que se autenticarem usando um login válido. Estas linhas devem ser colocadas antes de qualquer outra regra que libere o acesso, já que, se o acesso é aceito por uma regra anterior, ele não passa pela regra que exige autenticação.Entretanto, se você usar uma configuração similar a essa:auth_param basic realm Squidauth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/squid_passwdacl autenticados proxy_auth REQUIREDhttp_access allow autenticadosacl redelocal src 192.168.1.0/24http_access allow localhosthttp_access allow redelocalhttp_access deny all... vai notar que a regra de autenticação essencialmente desativa a regra que bloqueia o acesso de usuários fora da rede local. Todos os usuários tem acesso ao prompt de autenticação e todos que se autenticam ganham acesso, mesmo que estejam utilizando endereços fora da faixa usada na rede. Para evitar isso, é necessário restringir o acesso de usuários fora da rede local antes da regra de autenticação. Veja um exemplo:# Bloqueia acessos de fora da rede local antes de passar pela autenticação:acl redelocal src 192.168.1.0/24

Page 14: Tutoriais Linux

http_access deny !redelocal# Outras regras de restrição vão aqui, de forma que o acesso seja negado # antes mesmo de passar pela autenticação:acl bloqueados url_regex -i "/etc/squid/bloqueados"http_access deny bloqueados# Autentica o usuário:auth_param basic realm Squidauth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/squid_passwdacl autenticados proxy_auth REQUIREDhttp_access allow autenticados# Libera o acesso da rede local e do localhost para os autenticados, # bloqueia os demais:http_access allow localhosthttp_access allow redelocalhttp_access deny allVeja que agora usamos a regra "http_access deny !redelocal" no início da cadeia. A exclamação inverte a lógica da regra, fazendo com que ela bloqueie todos os endereços que não fizerem parte da acl "redelocal".Ao implementar a autenticação, você passa a poder criar regras de acesso com base nos logins dos usuários e não mais apenas com base nos endereços IP. Imagine, por exemplo, que você queira que apenas dois usuários da rede tenham acesso irrestrito ao proxy. Os demais (mesmo depois de autenticados), poderão acessar apenas no horário do almoço, e quem não tiver login e senha válidos não acessa em horário nenhum. Neste caso, você poderia usar esta configuração:auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/squid_passwdacl autenticados proxy_auth REQUIREDacl permitidos proxy_auth servidor tuxacl almoco time 12:00-13:00http_access allow permitidoshttp_access allow autenticados almocoAqui temos os usuários que passaram pela autenticação divididos em duas regras. A acl "autenticados" inclui todos os usuários, enquanto a acl "permitidos" contém apenas os usuários servidor e tux.Graças à regra "http_access allow permitidos", os dois podem acessar em qualquer horário, enquanto os demais caem na regra "http_access allow autenticados almoco", que cruza o conteúdo das acls "autenticados" e "almoço", permitindo que eles acessem, mas apenas das 12:00 às 13:00.Além do módulo ncsa_auth que, como vimos, permite usar um arquivo de senhas separado, válido apenas para o proxy, o Squid suporta também um conjunto de módulos que permitem fazer com que o Squid se autentique em um externo, integrando o proxy a um sistema de autenticação já existente.O mais simples é o módulo smb_auth, que permite que o Squid autentique os usuários em um Samba, configurado como PDC. Com isso, os usuários passam a utilizar o mesmo login e senha que utilizam para fazer logon. Para usar o smb_auth, você usaria a configuração a seguir, especificando o domínio (na opção -W) e o endereço do PDC (na opção -U):auth_param basic realm Squidauthenticate_ip_ttl 5 minutesauth_param basic program /usr/lib/squid/smb_auth -W dominio -U 192.168.1.254acl autenticados proxy_auth REQUIREDhttp_access allow autenticadosCom o módulo smb_auth, o Squid simplesmente repassa o login e senha fornecido pelo usuário ao PDC e autoriza o acesso caso o PDC retorne uma resposta positiva. Não é necessário que o com o Squid faça parte do domínio, nem que exista uma cópia do Samba rodando localmente (são necessários apenas os pacotes "samba-client" e "samba-common", que correspondem ao cliente Samba), por isso a configuração é bastante simples. Naturalmente, para utilizar esta configuração você deve ter um PDC na sua rede, como aprenderemos a configurar em detalhes no capítulo sobre o Samba.Outros módulos que podem ser usados são o "squid_ldap_auth", que permite que o autentique os usuários em um LDAP e o "ntlm_auth", que permite integrar o Squid ao Active Directory.

Configurando um proxy transparente

Uma garantia de que os usuários realmente vão usar o proxy e, ao mesmo tempo, uma grande economia de trabalho e dor de cabeça para você é o recurso de proxy transparente. Ele permite configurar o Squid e o firewall de forma que o proxy fique escutando todas as conexões na porta 80. Mesmo que alguém tente

Page 15: Tutoriais Linux

desabilitar o proxy manualmente nas configurações do navegador, ele continuará sendo usado. Outra vantagem é que este recurso permite usar o proxy sem precisar configurar manualmente o endereço em cada estação. Basta usar o endereço IP do rodando o proxy como gateway da rede.

Lembre-se de que, para usar o proxy transparente, você já deve estar compartilhando a conexão no via NAT, como vimos anteriormente. O proxy transparente apenas fará com que o proxy intercepte os acessos na porta 80, obrigando tudo a passar pelas suas regras de controle de acesso, log, autenticação e cache, diferente de um proxy tradicional, onde você não ativa o compartilhamento via NAT, fazendo com que o proxy seja a única porta de saída da rede.

Para ativar o proxy transparente, rode o comando abaixo. Ele direciona as requisições recebidas na porta 80 para o Squid:# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j \REDIRECT --to-port 3128

O "eth0" no comando indica a placa da rede local, onde o proxy recebe as requisições dos outros micros da rede e o "3128" indica a porta usada pelo Squid. Adicione o comando junto com os 4 comandos que compartilham a conexão no final do arquivo "/etc/rc.local" ou ao seu script de firewall para que ele seja executado durante o boot.

Finalmente, você precisa ativar o suporte ao modo transparente dentro do arquivo "/etc/squid/squid.conf" e reiniciar o serviço.Se você está usando uma versão recente, do Squid 2.6 em diante, a configuração é mais simples. Basta substituir a linha "http_port 3128" no início do arquivo por:

http_port 3128 transparent

Ou seja, na verdade você precisa apenas adicionar o "transparent" para que o Squid passe a entender as requisições redirecionadas pela regra do firewall.

No caso das versões mais antigas, anteriores à 2.6 (como a usada no Debian Sarge e no Ubuntu 5.10), é necessário adicionar as quatro linhas abaixo, no final do arquivo "/etc/squid/squid.conf" (nesse caso, sem alterar a linha "http_port 3128"):

httpd_accel_host virtualhttpd_accel_port 80httpd_accel_with_proxy onhttpd_accel_uses_host_header on

Em qualquer um dos dois casos, você precisa reiniciar o serviço para que a alteração entre em vigor:# /etc/init.d/squid restart

Em caso de dúvida sobre qual versão do Squid está instalada, use o comando "squid -v", que além de reportar a versão, informa todas as opções que foram usadas durante a compilação:# squid -v

Squid Cache: Version 2.6.STABLE2configure options: '--prefix=/usr' '--exec_prefix=/usr' '--bindir=/usr/sbin' '--sbindir=/usr/sbin' '--libexecdir=/usr/lib/squid' '--sysconfdir=/etc/squid' '--localstatedir=/var/spool/squid' '--datadir=/usr/share/squid' '--enable-async-io' '--with-pthreads' '--enable-storeio=ufs,aufs,diskd,null' '--enable-linux-netfilter' '--enable-linux-proxy' '--enable-arp-acl' '--enable-epoll' '--enable-removal-policies=lru,heap' '--enable-snmp' '--enable-delay-pools' '--enable-htcp' '--enable-cache-digests' '--enable-underscores' '--enable-referer-log' '--enable-useragent-log' '--enable-auth=basic,digest,ntlm' '--enable-carp' '--with-large-files' 'i386-debian-linux' 'build_alias=i386-debian-linux' 'host_alias=i386-debian-linux' 'target_alias=i386-debian-linux'

Em resumo, ao usar o proxy transparente você vai ter a conexão compartilhada via NAT no e configurará os clientes para acessar através dela, colocando o como gateway da rede. Ao ativar o proxy, a configuração dos clientes continua igual, a única diferença é que agora (graças à nova regra do Iptables) todo o tráfego da porta 80 passará, obrigatoriamente, pelo Squid. Isso permite que você se beneficie do log dos acessos e do cache feito pelo proxy, sem ter que se sujeitar às desvantagens de usar um proxy, como ter que configurar manualmente cada estação.

Page 16: Tutoriais Linux

Uma observação importante é que esta configuração de proxy transparente não funciona em conjunto com o sistema de autenticação incluso no Squid. Ao usar o proxy transparente a autenticação deixa de funcionar, fazendo com que você precise escolher entre as duas coisas.

Outra limitação importante do uso do proxy transparente é que ele atende apenas ao tráfego da porta 80. Como a conexão é compartilhada via NAT, todo o tráfego de outros protocolos (incluindo páginas em HTTPS, que são acessadas através da porta 443) é encaminhado diretamente, sem passar pelo proxy. Ou seja, embora seja uma forma simples de implementar um sistema de cache e algumas restrições de acesso, o uso do proxy transparente está longe de ser uma solução ideal.

Em situações onde você realmente precisa ter controle sobre o tráfego da rede, a única opção acaba sendo utilizar um proxy "normal", sem NAT. Uma solução para reduzir seu trabalho de administração nesse caso é implantar um sistema de configuração automática de proxy nos clientes.Mais detalhes sobre a configuração dos caches

A configuração dos caches é o parâmetro da configuração que afeta mais diretamente o desempenho do proxy e por isso deve ser sempre definida com cuidado em qualquer que irá atender a um grande volume de usuários. Embora a configuração pareça simples, ela na verdade esconde diversos detalhes pouco intuitivos.

Como comentei a pouco, em um de rede local que atende um pequeno volume de clientes, você pode reservar apenas 32 ou 64 MB de memória RAM para o cache do Squid (de forma que ele não consuma toda a memória do , prejudicando seu desempenho em outras tarefas) e, em um dedicado para uma rede de maior porte você pode reservar até 1/3 da memória total do . Você deve ter se perguntado por que reservar apenas 1/3 da memória, se a função do será rodar apenas o proxy. Porque não reservar logo toda a memória para o Squid?

A resposta é que além da RAM reservada ao cache em memória, o Squid precisa de memória RAM para diversas outras tarefas, incluindo o gerenciamento das conexões e armazenamento da metadata dos arquivos armazenados no cache em disco, sem falar da memória RAM consumida pelo sistema operacional para fazer cache de disco e outras atividades. Reservando muita memória para o cache, o sistema é obrigado a utilizar memória swap, o que acaba reduzindo o desempenho em vez de aumentar.

Em uma pequena rede, raramente o desempenho do HD será um gargalo, já que o proxy precisará atender a um pequeno volume de requisições. Entretanto, em uma grande rede, com mais do que 100 ou 200 clientes o desempenho do proxy é freqüentemente gargalado pelo volume de leituras que o HD é capaz de realizar.

Uma dica nesse caso é utilizar HDs SATA (ou SCSI) com suporte a NCQ; neles a controladora pode realizar leituras fora de ordem, levando em conta a posição dos arquivos nos discos magnéticos. Isso faz com que eles sejam capazes de realizar um volume de leituras de pequenos arquivos muito maior do que HDs IDE e HDs SATA sem NCQ (em algumas situações específicas, até duas vezes mais), o que melhora assustadoramente o desempenho em es proxy. Verifique também a possibilidade de adicionar mais memória RAM ao , já que com um cache maior na memória RAM, menos arquivos precisarão ser lidos a partir do HD.

Outra dica é que você pode reduzir bastante o volume de operações de acesso a disco fazendo com que o cache despreze arquivos muito pequenos (menores do que 2 KB, por exemplo) através da opção "minimum_object_size", como em:

maximum_object_size 512 MBminimum_object_size 2 KB

Isso faz com que pequenas imagens e outros tipos de arquivos muito pequenos, usados em profusão em muitas páginas web sejam simplesmente baixados novamente a cada acesso, em vez de precisarem ser lidos no cache do HD. Como os arquivos são muito pequenos, o aumento no uso do link não deve ser considerável.

Continuando, se você precisar alterar a localização da pasta do cache na linha "cache_dir" (para colocá-lo em uma pasta em uma partição separada, por exemplo), você vai logo perceber que o Squid deixará de inicializar, acusando um erro de permissão no diretório do cache, como nesse exemplo:

Page 17: Tutoriais Linux

Restarting Squid HTTP proxy: squid* Creating squid spool directory structure2008/06/31 16:35:46| Creating Swap DirectoriesFATAL: Failed to make swap directory /mnt/sda2/squid/00: (13) Permission deniedSquid Cache (Version 2.6.STABLE5): Terminated abnormally.CPU Usage: 0.000 seconds = 0.000 user + 0.000 sysMaximum Resident Size: 0 KBPage faults with physical i/o: 0

Para solucionar o problema, pare o Squid, ajuste as permissões da nova pasta, de forma que a posse seja transferida para o usuário "proxy" e o grupo "proxy" (usados pelo Squid) e, para concluir, execute o comando "squid -z", que faz com que ele reformate o diretório do cache, criando a estrutura apropriada:# /etc/init.d/squid stop# chown -R proxy.proxy /mnt/sda2/squid# squid -z# /etc/init.d/squid start

Em versões antigas do Squid você ficava limitado a um único diretório de cache, de forma que a única forma de adicionar uma nova partição era realmente movendo o cache para ela. Nas versões atuais (desde o Squid 2.0) existe a opção de simplesmente adicionar novas linhas "cache_dir" na configuração, sem apagar as antigas. Isso permite que você simplesmente adicione novas pastas e partições ao cache, mantendo as antigas, como em:

cache_dir ufs /var/spool/squid 2048 16 256cache_dir ufs /mnt/sda2/squid 5120 16 256cache_dir ufs /mnt/sda3/squid 10240 16 256

Não esqueça de que, ao adicionar uma nova pasta, você deve parar o proxy, ajustar as permissões de acesso e rodar o comando "squid -z" para que o Squid crie as estruturas necessárias, como no exemplo anterior.Note que, mesmo ao usar uma partição separada só para o cache, você não deve 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 do cache e para operações de organização em geral, sem falar que é importante manter uma pequena percentagem de espaço livre na partição para reduzir a fragmentação. Se você tiver uma partição de 10 GB e usar na configuração "cache_dir ufs /var/spool/squid 10480 16 256" (reservando exatamente 10 GB para o cache), o Squid vai travar depois de algum tempo, por falta de espaço em disco. O correto no caso seria usar "cache_dir ufs /var/spool/squid 8192 16 256", reservando 8 GB em vez de 10.

Uma observação final é que o volume de espaço em disco reservado ao cache tem efeito sobre o volume de memória RAM consumido pelo Squid (em adição ao cache na memória), pois o Squid precisa manter carregadas informações sobre os arquivos armazenados no cache para localizá-los de forma eficiente.

De uma forma geral, para cada gigabyte de espaço em disco reservado para o cache, o Squid consome cerca de 10 MB a mais de memória RAM (o valor real varia de acordo com o tamanho dos arquivos armazenados no cache), de forma que um cache de 20 GB, por exemplo, aumenta o volume de memória usado pelo Squid em aproximadamente 200 MB.

Devido a isso, não é recomendável usar um cache em disco muito grande, a menos que o realmente possua muita memória disponível e precise atender a um volume muito grande de clientes. Para um de rede local, um cache de 5 ou 10 GB já é mais do que suficiente.Usando o Sarg para monitorar o acesso

O Sarg é um interpretador de logs para o Squid, assim como o Webalizer é para o Apache. Sempre que executado, ele cria um conjunto de páginas, divididas por dia, com uma lista de todas as páginas que foram acessadas e a partir de que máquina da rede veio cada acesso. Caso você tenha configurado o Squid para exigir autenticação, ele organiza os acessos com base nos logins dos usuários. Caso contrário, ele mostra os endereços IP das máquinas.

A partir daí, você pode acompanhar as páginas que estão sendo acessadas (mesmo que não exista nenhum filtro de conteúdo) e tomar as medidas cabíveis em casos de abuso. Todos sabemos que os filtros de conteúdo nunca são completamente eficazes, eles sempre bloqueiam algumas páginas úteis e

Page 18: Tutoriais Linux

deixam passar muitas páginas impróprias. Se você tiver algum tempo para ir acompanhando os logs, a inspeção manual acaba sendo o método mais eficiente. Você pode ir fazendo um trabalho incremental, ir bloqueando uma a uma as páginas onde os usuários perdem muito tempo, ou fazer algum trabalho educativo, explicando que os acessos estão sendo monitorados e estabelecendo algum tipo de punição para quem abusar.Aqui está um exemplo do relatório gerado pelo Sarg. Por padrão, ele gera um conjunto de páginas html dentro da pasta "/var/www/squid-reports/" (ou "/var/www/html/squid/", nas distribuições derivadas do Red Hat), que você pode visualizar através de qualquer navegador:

Configurando um servidor DHCP

Hoje em dia, quase todas as redes utilizam algum tipo de DHCP. Em geral, eles são ativados automaticamente ao compartilhar a conexão ou junto com algum outro serviço, de forma que você acaba não aprendendo muita coisa sobre a sua configuração.

De um modo geral, o trabalho de um 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 "255.255.255.255" e são retransmitidos pelo switch da rede para todas as portas, diferente dos pacotes endereçados a um endereço específico, que são transmitidos apenas na porta relacionada a ele.

Periodicamente o DHCP verifica se as estações ainda estão lá, exigindo uma renovação do "aluguel" do endereço IP (opção "lease time"). Isso permite que os endereços IP sejam gastos apenas com quem realmente estiver online, evitando que os endereços disponíveis se esgotem.O DHCP mais usado no Linux é o ISC DHCP, desenvolvido pela Internet Systems Consortium, uma organização sem fins lucrativos dedicada a desenvolver serviços de infra-estrutura usados na Internet, incluindo o Bind e o NTPD. Caso esteja curioso, a página com o código fonte é a: http://www.isc.org/sw/dhcp/.

Nas distribuições derivadas do Debian, o pacote correspondente ao DHCP se chama "dhcp3-server" e pode ser instalado via apt-get:# apt-get install dhcp3-server

Com o pacote instalado, você pode ativar e desativar o serviço usando os comandos:# /etc/init.d/dhcp3-server start# /etc/init.d/dhcp3-server stop

Como você pode imaginar, o "3" corresponde à versão do software. Eventualmente ele será substituído pelo "dhcp4-server", o que resultará também na mudança do nome da pasta onde fica o arquivo e do script de inicialização referente ao serviço.

No Fedora e no CentOS, o pacote se chama simplesmente "dhcp" e pode ser instalado usando o yum:# yum install dhcp

Embora o pacote se chame apenas "dhcp", o script referente ao serviço se chama "dhcpd", de forma que os comandos para iniciar e parar o serviço são:# service dhcpd start# service dhcpd stop

Diferente do Debian, o serviço não será configurado para ser inicializado durante o boot depois de instalado. Você precisa ativá-lo manualmente usando o comando "chkconfig":# chkconfig dhcpd onO arquivo de configuração é o "dhcpd.conf". Nas distribuições derivadas do Debian, o caminho completo para ele é "/etc/dhcp3/dhcpd.conf", enquanto no Fedora e no CentOS é apenas "/etc/dhcpd.conf", ou seja, um diretório acima.

Apesar dessas diferenças estéticas, o que interessa mesmo é a configuração do arquivo e esta sim é igual, independentemente da distribuição. Este é um exemplo de arquivo de configuração básico:

# /etc/dhcp3/dhcpd.conf

Page 19: Tutoriais Linux

ddns-update-style none;default-lease-time 600;max-lease-time 7200;authoritative;subnet 192.168.1.0 netmask 255.255.255.0 {range 192.168.1.100 192.168.1.199;option routers 192.168.1.1;option domain-name-servers 208.67.222.222,208.67.220.220;option broadcast-address 192.168.1.255;}

A opção " default-lease-time" controla o tempo de renovação dos endereços IP. O "600" indica que o verifica a cada dez minutos se as estações ainda estão ativas. Se você tiver mais endereços IP do que máquinas, os endereços IP das estações raramente vão precisar mudar. Mas, no caso de uma rede congestionada, o "max-lease-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, como, por exemplo, em um provedor de acesso, onde sempre existem mais clientes do que endereços IP disponíveis e se trabalha contando que nem todos vão ficar conectados simultaneamente. Em condições normais, essas duas opções não são muito importantes. O que interessa mesmo é o bloco que vai logo abaixo, onde ficam as configurações da rede.A opção "range" determina a faixa de endereços IP que será usada pelo . Se você utiliza a faixa de endereços 192.168.1.1 até 192.168.1.254, por exemplo, pode reservar os endereços de 192.168.1.1 a 192.168.1.100 para estações configuradas com IP fixo e usar os demais para o DHCP, ou então reservar uma faixa específica para ele, de 192.168.1.101 a 192.168.1.201, por exemplo. O importante é usar faixas separadas para o DHCP e os micros configurados com IP fixo.Na "option routers" vai o endereço do default gateway da rede, ou seja, o endereço do que está compartilhando a conexão. Não é necessário que o mesmo micro que está compartilhando a conexão rode também o DHCP. Pode ser, por exemplo, que na sua rede o gateway seja o próprio modem ADSL que está compartilhando a conexão e o DHCP seja um dos PCs.A opção "option domain-name-servers" contém os es DNS que serão usados pelas estações. Ao usar dois ou mais endereços, eles devem ser separados por vírgula, sem espaços. Em geral, você vai usar os próprios endereços DNS do provedor, a menos que você configure um DNS interno na sua rede (que pode ser instalado no próprio micro que está compartilhando a conexão e rodando o DHCP). Estes serviços consomem poucos recursos da máquina. 

Você pode substituir o arquivo de configuração padrão por este modelo, ou editá-lo conforme a necessidade. Ao fazer qualquer alteração no arquivo, você deve reiniciar o DHCP usando o comando:# /etc/init.d/dhcp3-server restartou:# service dhcpd restart

Com o DHCP configurado, você pode testar a configuração em um dos clientes Linux, configurando a rede usando o "dhclient", seguido da interface a ser configurada. Ele mostra toda a negociação entre o e o cliente, o que permite que você verifique se o está usando a configuração definida por você:# dhclient eth0

Internet Systems Consortium DHCP Client V3.0.4Copyright 2004-2006 Internet Systems Consortium.All rights reserved.For info, please visit http://www.isc.org/sw/dhcp/Listening on LPF/eth1/00:15:00:4b:68:dbSending on LPF/eth1/00:15:00:4b:68:dbSending on Socket/fallbackDHCPREQUEST on eth1 to 255.255.255.255 port 67DHCPACK from 192.168.1.1bound to 192.168.1.199 -- renewal in 245 seconds.

Como você pode ver, o cliente deve receber a resposta a partir do endereço IP do rodando o DHCP e ser configurado com um endereço dentro da faixa definida por você.

Page 20: Tutoriais Linux

Uma observação importante é que sempre que configurar um com duas placas de rede, você deve configurar o DHCP para escutar apenas na placa da rede local. No Debian, esta configuração vai no arquivo "/etc/default/dhcp3-server". Procure pela linha:

INTERFACES=""

... e adicione a placa que o DHCP deve escutar, como em:INTERFACES="eth0"

Para que a configuração entre em vigor, basta reiniciar o serviço novamente.

Configurando Servidor Samba

Como comentei a pouco, o Samba é dividido em dois módulos. O 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

apenas nas máquinas que realmente forem compartilhar arquivos. Isso permite melhorar a segurança da

rede de uma forma geral.

Os pacotes do Samba recebem nomes um pouco diferentes nas distribuições derivadas do Debian

(incluindo o Ubuntu, Kubuntu e outras) e no Fedora (e outras distribuições derivadas do Red Hat, como o

CentOS). Veja:

Pacote Debian Fedora

: samba samba

Cliente: smbclient samba-client

Documentação samba-doc samba-doc

Swat: swat samba-swat

Para instalá-lo no Debian ou Ubuntu, por exemplo, você usaria:

# apt-get install samba smbclient swat samba-doc

O script de instalação faz duas perguntas. A primeira é se o deve rodar em modo daemon ou sob o inetd.

Responda "daemons" para que o rode diretamente. Isso garante um melhor desempenho, melhor

segurança e evita problemas diversos de configuração relacionados ao uso do inetd, serviço que está

entrando em desuso.

Page 21: Tutoriais Linux

Em seguida ele pergunta: "Gerar a base de dados para senhas /var/lib/samba/passdb.tdb?". É importante

responder que "Sim", para que ele crie o arquivo onde serão armazenadas as senhas de acesso. Como

explica o script, "Caso você não o crie, você terá que reconfigurar o samba (e provavelmente suas

máquinas clientes) para utilização de senhas em texto puro", o que é um procedimento trabalhoso, que

consiste em modificar chaves de registro em todas as máquinas Windows da rede e modificar a

configuração de outros es Linux. Muito mais fácil responder "Sim" e deixar que ele utilize senhas

encriptadas, que é o padrão. :)

Lembre-se de que você deve instalar todos os pacotes apenas no e em outras máquinas que forem

compartilhar arquivos. O Swat pode ajudar 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.

No Fedora e no CentOS a instalação é feita usando o yum:

# yum install samba samba-client samba-doc samba-swat

O Fedora inclui mais um pacote, o "system-config-samba", um utilitário de configuração rápida, que

permite criar e desativar compartilhamentos de forma bem prática. Outro configurador rápido é o módulo

"Internet & Rede > Samba", disponível no Painel de Controle do KDE. Aqui abordo apenas a configuração

manual e o uso do Swat, que é o configurador mais completo, mas você pode lançar mão destes dois

utilitários para realizar configurações rápidas.

Com os pacotes instalados, use os comandos:

# /etc/init.d/samba start

# /etc/init.d/samba stop

... para iniciar e parar o serviço. Por padrão, ao instalar o pacote é criado um link na pasta "/etc/rc5.d", que

ativa o automaticamente durante o boot. Para desativar a inicialização automática, use o comando:

# update-rc.d -f samba remove

Pata reativá-lo mais tarde, use:

# update-rc.d -f samba defaults

No Fedora, CentOS e no Mandriva, os comandos para iniciar e parar o serviço são:

# service smb start

# service smb stop

Para desabilitar o carregamento durante o boot, use o "chkconfig smb off" e, para reativar, use o

"chkconfig smb on". Note que, em ambos, o pacote de instalação se chama "samba", mas o serviço de

sistema chama-se apenas "smb".

É sempre recomendável utilizar os pacotes que fazem parte da distribuição, que são compilados e

otimizados para o sistema e recebem atualizações de segurança regularmente. De qualquer forma, você

pode encontrar também alguns pacotes compilados por colaboradores

nohttp://samba.org/samba/ftp/Binary_Packages/, além do código fonte, disponível

Page 22: Tutoriais Linux

no http://samba.org/samba/ftp/stable/. Ao instalar a partir do código fonte, o Samba é instalado por default

na pasta "/usr/local/samba", com os arquivos de configuração na pasta "/usr/local/samba/lib".

Este texto é baseado no Samba 3 que, enquanto escrevo, é a versão estável, recomendada para

ambientes de produção. O Samba 3 trouxe suporte ao Active Directory, passou a ser capaz de atuar como

PDC, trouxe muitas melhorias no suporte a impressão e inúmeras outras melhorias em relação à série 2.x.

O Samba 3.0.0 foi lançado em setembro de 2003, ou seja, há mais de 4 anos. Comparado com os ciclos

de desenvolvimento das distribuições Linux, que são em sua maioria atualizadas a cada 6 ou 12 meses, 4

anos podem parecer muita coisa, mas se compararmos com os ciclos de desenvolvimento de novas

versões do Windows, por exemplo, os ciclos parecem até curtos :). Para efeito de comparação, o Samba

2 (o major release anterior) foi lançado em 1999 e o Samba 4 está (em junho de 2008) em estágio de

desenvolvimento, ainda sem previsão de conclusão.

Por ser um software utilizado em ambientes de produção, novas versões do Samba são exaustivamente

testadas antes de serem consideradas estáveis e serem oficialmente lançadas. Graças a isso, é muito

raro o aparecimento de bugs graves e, quando acontecem, eles costumam ser corrigidos muito

rapidamente.

Naturalmente, as versões de produção continuam sendo atualizadas e recebendo novos recursos. Entre o

Samba 3.0.0 lançado em 2003 e o Samba 3.0.24 incluído no Debian Etch, por exemplo, foram lançadas

nada menos do que 28 minor releases intermediários. Se tiver curiosidade em ler sobre as alterações em

cada versão, pode ler o change-log de cada versão no: http://samba.org/samba/history/.

Você pode verificar qual é a versão do Samba instalada usando o comando "smbd -V", como em:

# smbd -V

Version 3.0.24

Ao usar qualquer distribuição atual, muito provavelmente você encontrará o Samba 3.0.23 ou superior. Se

por acaso você estiver usando alguma distribuição muito antiga, que ainda utilize uma versão do Samba

anterior à 3.0.0, recomendo que atualize o sistema, já que muitos dos recursos que cito ao longo do texto,

sobretudo o uso do Samba como PDC, não funcionam nas versões da série 2.x.

Para usar o Samba em conjunto com estações rodando o Windows Vista, você deve utilizar o Samba

versão 3.0.22, ou superior, que oferece suporte ao protocolo NTLMv2, que é o protocolo de autenticação

utilizado por padrão pelo Windows Vista.

Se não for possível atualizar o Samba, a segunda opção é configurar as estações com o Vista para

permitirem o uso do sistema NTLM, o que é feito através do utilitário "secpol.msc" em "Diretivas locais >

Opções de segurança > Segurança de rede: nível de autenticação Lan Manager", alterando o valor da

opção de "Enviar somente resposta NTLMv2" para "Enviar LM e NTLM - use a segurança da sessão

NTLMv2, se negociado".Cadastrando os usuários

Depois de instalar o Samba, o próximo passo é cadastrar os logins e senhas dos usuários que terão

acesso ao . 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. 

Page 23: Tutoriais Linux

Existem duas abordagens possíveis. A primeira é criar usuários "reais", usando o comandoadduser 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. Essa abordagem é

mais segura, pois os usuários não poderão acessar o via SSH ou Telnet, por exemplo, o que abriria

brecha para vários tipos de ataques. Nesse caso, você cria os usuários adicionando os parâmetros que

orientam o adduser a não criar o diretório home e a manter a conta desativada até segunda ordem:

# adduser --disabled-login --no-create-home maria

Isso 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 que, por outro lado, não pode fazer login (nem

localmente, nem remotamente via SSH), nem possui diretório home.

Uma dica é que no Fedora e no CentOS (e outras distribuições derivadas do Red Hat), você só consegue

usar o comando caso logue-se como root usando o comando "su -" ao invés de simplesmente "su". A

diferença entre os dois é que o "su -" ajusta as variáveis de ambiente, incluindo o PATH, ou seja, as

pastas onde o sistema procura pelos executáveis usados nos comandos. Sem isso, o sistema não

encontra o executável do adduser, que vai na pasta "/usr/sbin".

Os parâmetros suportados pelo adduser também são um pouco diferentes. O padrão já é criar um login

desabilitado (você usa o comando "passwd usuário" para ativar) e, ao invés do "--no-create-home", usa a

opção "-M". O comando (no Fedora) fica, então:

# adduser -M maria

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

e, por outro lado, você precisar remover o usuário definitivamente, use o parâmetro "-x" (exclude), seguido

pelo comando "deluser", que remove o usuário do sistema, como em:

# smbpasswd -x maria

# deluser maria

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 o

arquivo de configuração do Samba, o "/etc/samba/smb.conf", como veremos mais adiante. As opções

que podem ser usadas no arquivo são as mesmas que aparecem nas páginas do Swat, de forma que

você pode até mesmo combinar as duas coisas, configurando através do Swat e fazendo pequenos

ajustes manualmente, ou vice-versa.

Clique aqui para ver a primeira parte

Como vimos na primeira parte do tutorial, a maior parte da configuração do Samba, incluindo as

configurações gerais do , impressoras e todos os compartilhamentos, é feita em um ú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 dentro da interface. Isso permite que o Swat coexista com a edição manual do arquivo. Como

Page 24: Tutoriais Linux

comentei a pouco, o Swat remove todos os seus comentários e formatação (deixando apenas as opções),

por isso muitos evitam usá-lo.

Apesar disso, o formato do arquivo de configuração do Samba é bastante simples e por isso muitas vezes

é mais rápido e até mais simples editar diretamente o arquivo do que fazê-lo através do Swat. Ao instalar

o Samba, é criado um arquivo de configuração de exemplo, com vários comentários. Assim como no caso

do Squid, ele é longo e difícil de entender, por isso acaba sendo mais fácil renomeá-lo e começar com um

arquivo em branco, ou usar como base a configuração gerada através do Swat.

Vamos então a uma segunda rodada de explicações sobre a configuração do Samba, agora editando

diretamente o arquivo smb.conf e explorando com maior profundidade as opções disponíveis. Vamos

começar com um exemplo simplista, onde temos um único compartilhamento de teste:

[global]

netbios name = Sparta

workgroup = Grupo

[arquivos]

path = /mnt/arquivos

comment = Teste

Como você pode ver, o arquivo é dividido em seções. A primeira é sempre a seção "[global]", que contém

as opções gerais do . Por enquanto, definimos apenas o nome do (netbios name) e o nome do grupo de

trabalho (workgroup), que seria o mínimo necessário para colocar o na rede. As demais opções (não

especificadas no arquivo) são configuradas usando os valores default. Se você omitir a opção

"workgroup", por exemplo, o Samba vai reverter para o grupo "WORKGROUP", que é o padrão.

Se quiser, você pode também adicionar uma descrição para o , o que é feito através da opção "server

string" (adicionada dentro da seção [global]), como em:

server string = Samba

Duas dicas são que:

a) O default do Samba é usar a string "Samba 3.0.24" (onde o "3.0.24" é a versão usada) como descrição

quando a opção "server string" não está presente no arquivo.

b) Nas máquinas com o Windows XP, a descrição do aparece antes do nome propriamente dito, como

em " Samba (Sparta)". É importante levar isso em consideração, já que, no final das contas, o que importa

é o que os usuários irão ver ao navegar pelo ambiente de redes:

Abaixo da seção [global], incluímos seções adicionais para cada compartilhamento, que é o caso da

seção "[arquivos]" que cria o compartilhamento de teste.

O "[arquivos]" indica o nome do compartilhamento, da forma como ele aparecerá na rede. Logo a seguir

temos a linha "path", que diz qual pasta do será compartilhada e a linha "comment" (opcional), que

permite que você inclua um comentário.

Sempre que alterar manualmente o smb.conf, ou mesmo alterar algumas opções pelo Swat e quiser

verificar se as configurações estão corretas, rode o comando testparm. Ele funciona como uma espécie

de debug, indicando erros grosseiros no arquivo e informando o papel do na rede:

# testparm

Page 25: Tutoriais Linux

Load smb config files from /etc/samba/smb.conf

Processing section "[arquivos]"

Loaded services file OK.

Server role: ROLE_STANDALONE

O "ROLE_STANDALONE" significa que o foi configurado como um membro normal do grupo de trabalho.

É possível também fazer com que o Samba atue como um controlador de domínio, como veremos em

detalhes mais adiante.

Em caso de erros no arquivo, o testparm ajuda a localizar o problema, indicando a linha ou opção inválida,

de forma que você possa corrigí-la. Veja o que acontece ao adicionar um erro simples, usando a linha

"wrritable = yes" no lugar de "writable = yes":

Unknown parameter encountered: "wrritable"

Ignoring unknown parameter "wrritable"

O Samba não diferencia o uso de maiúsculas e minúsculas nas opções, de forma que tanto faz escrever

"writable = yes", "writable = Yes" ou "writable = YES". Entretanto, muitos dos parâmetros não são

diretamente usados pelo Samba, mas sim repassados ao sistema que, diferentemente do Samba,

diferencia os caracteres. Um exemplo são as localizações de pastas a compartilhar. Se você escrever

"path = /mnt/Arquivos" (em vez de "path = /mnt/arquivos"), o compartilhamento não vai funcionar, pois o

sistema reportará que a pasta não existe.

Além do caractere "#", é possível usar também o ";" para comentar linhas. A principal observação é que

você não pode inserir comentários em linhas válidas (mesmo que no final da linha), pois, ao fazer isso,

toda a linha passa a ser ignorada pelo Samba. Neste exemplo, o comentário foi incluído na linha "path", o

que acaba por desativar o compartilhamento completamente:

[teste]

path = /mnt/arquivos # Pasta compartilhada

comment = Compartilhamento que não funciona

O testparm também não indica o erro diretamente, já que ele também considera a linha como um

comentário, o que pode levá-lo a perder um bom tempo tentando descobrir onde está o problema. Ao

incluir comentários no arquivo, use sempre linhas separadas:

[teste]

# Pasta compartilhada

path = /mnt/arquivos

comment = Agora sim

As alterações no arquivo são lidas periodicamente pelo Samba (o default são 3 minutos) e aplicadas

automaticamente. Isso permite que as mudanças de configuração sejam aplicadas de forma suave, sem

prejudicar o acesso dos usuários, o que é importante em um ambiente de produção. Para fazer com que

as alterações entrem em vigor imediatamente, reinicie o serviço do Samba, como em:

# /etc/init.d/samba restart

ou:

Page 26: Tutoriais Linux

# service smb restart

A partir daí, o compartilhamento estará disponível. Ao tentar acessar o através do "Meus locais de rede"

nos clientes Windows, você receberá um prompt de senha, onde você precisa fornecer um dos logins

cadastrados no usando o comando "smbpasswd -a":

É importante enfatizar que todos os usuários cadastrados no Samba precisam também existir no sistema,

por isso, antes de usar o comando "smbpasswd -a", você deve usar o adduser para criar o usuário. Como

citei anteriormente, a solução para casos em que você não deseja criar contas válidas para todos os

usuários é criar usuários limitados usando o comando "adduser --disabled-login --no-create-home usuario"

ou "adduser -M usuario".

Depois de logado, o cliente pode visualizar os compartilhamentos do . Por enquanto temos apenas o compartilhamento "arquivos", que mostra o conteúdo da pasta "/mnt/arquivos" do , mas ao longo do tutAjustando as permissões de acesso

Com esta configuração, os clientes conseguem visualizar os arquivos da pasta normalmente, mas ainda

não conseguem gravar nos arquivos. Ao tentar salvar alguma coisa na pasta, você recebe uma

mensagem de acesso negado:

Page 27: Tutoriais Linux

Isso acontece por dois motivos. O primeiro é que o default do Samba é compartilhar com permissão

apenas para leitura. Como não dissemos nada sobre as permissões de acesso do compartilhamento no

arquivo de configuração, ele foi compartilhado usando o default.

Para que o compartilhamento fique disponível com permissão de leitura e escrita, precisamos adicionar a

opção "writable = yes" dentro da configuração do compartilhamento, que ficará:

[arquivos]

path = /mnt/arquivos

writable = yes

comment = Teste

Muito provavelmente, mesmo depois de reiniciar o Samba você continuará recebendo o mesmo erro ao

tentar gravar os arquivos. Dessa vez, o Samba autoriza a gravação, mas ela ainda pode ser abortada se

as permissões da pasta não permitirem que o usuário grave arquivos. Se você criou a pasta

"/mnt/arquivos" como root, então o default é que apenas ele possa gravar arquivos na pasta. Para permitir

que outros usuários possam gravar, é necessário abrir as permissões da pasta.

A esta altura, a lei do mínimo esforço diria para você usar um:

# chmod 777 /mnt/arquivos

Obviamente, isso permitiria que os usuários gravassem na pasta. O problema é que as permissões

ficariam escancaradas, a ponto de qualquer um, que tenha acesso ao (por qualquer meio) possa alterar

os arquivos dentro da pasta, o que não é nada bom do ponto de vista da segurança.

No tópico sobre o Swat, vimos como criar um grupo usando o users-admin (system-config-users) e abrir

as permissões da pasta apenas para os usuários que fazem parte dele. Vamos ver agora como fazer isso

via linha de comando.

O primeiro passo é criar um grupo para os usuários que poderão fazer alterações na pasta, usando o

comando "groupadd". Eu prefiro criar grupos com o mesmo nome do compartilhamento, para ficar mais

fácil de lembrar, mas isso fica a seu critério.

Page 28: Tutoriais Linux

# groupadd arquivos

A partir daí, você pode adicionar usuários ao grupo usando o comando "adduser", nesse caso

especificando o usuário já criado e o grupo ao qual ele será adicionado, como em:

# adduser joao arquivos

# adduser maria arquivos

Para remover usuários do grupo, você usa o comando "deluser", como em:

# deluser joao arquivos

# deluser maria arquivos

Depois de criar o grupo e adicionar os usuários a ele, falta apenas ajustar as permissões de acesso da

pasta, de forma que o grupo tenha acesso completo, como em:

# chgrp arquivos /mnt/arquivos

# chmod 775 /mnt/arquivos

Com isso, trocamos o grupo dono da pasta e dizemos que tanto o dono quanto o grupo possuem acesso

completo. A partir desse ponto, o Samba autoriza o acesso para todos os usuários cadastrados através do

smbpasswd e o sistema autoriza a gravação para todos os usuários que fazem parte do grupo.

Se você precisar que a alteração seja aplicada de forma recursiva, alterando as permissões de todas as

subpastas e arquivos, adicione a opção "-R" nos dois comandos, como em:

# chgrp -R arquivos /mnt/arquivos

# chmod -R 775 /mnt/arquivos

Além de servirem para controlar as permissões de acesso dos usuários às pastas do sistema, os grupos

podem ser usados para ajustar as permissões de acesso do Samba, de forma bastante simples.

Se você quer que o compartilhamento fique disponível apenas para os usuários que cadastrou no grupo

"arquivos", adicione a opção "valid users = +arquivos" na seção referente ao compartilhamento. O "+"

indica que se trata de um grupo e não de um usuário isolado. O Samba verifica então quais usuários

fazem parte do grupo e autoriza o acesso. A partir daí, quando você quiser liberar o acesso para um novo

usuário, basta adicioná-lo ao grupo:

[arquivos]

path = /mnt/arquivos

writable = yes

valid users = +arquivos

Você pode também especificar uma lista de usuários isolados, separando-os por vírgula, por espaço, ou

pelos dois combinados (o que preferir), como em:

[arquivos]

path = /mnt/arquivos

Page 29: Tutoriais Linux

writable = yes

valid users = joao, maria, jose

É possível também combinar as duas coisas, indicando um ou mais grupos e também alguns usuários

avulsos, como em:

[arquivos]

path = /mnt/arquivos

writable = yes

valid users = +arquivos, jose, joaquim, +admin

Assim como na maioria das opções do Samba, a opção "valid users" é exclusiva, ou seja, ao dizer que os

usuários do grupo arquivos devem ter acesso, você automaticamente exclui todos os outros. Você pode

também fazer o oposto, criando uma lista de usuários que não devem ter acesso e mantendo o acesso

para os demais. Nesse caso, você usaria a opção "invalid users", como em:

[arquivos]

path = /mnt/arquivos

writable = yes

invalid users = jose, joaquim

Nesse caso, todos os usuários cadastrados no Samba podem acessar, com exceção dos usuários jose e

joaquim. É possível ainda usar a opção "invalid users" para especificar exceções ao especificar grupos

usando a opção "valid users", como em:

[arquivos]

path = /mnt/arquivos

writable = yes

valid users = +arquivos

invalid users = joao

Nesse caso, todos os usuários dentro do grupo arquivos terão acesso, com exceção do joao. Esta

combinação pode ser usada em casos onde o grupo é especificado também em outros compartilhamentos

e você precisa bloquear o acesso do usuário a um compartilhamento específico, sem removê-lo do grupo.

É possível também criar uma lista de escrita, usando a opção "write list". Ela cria uma camada adicional

de proteção, permitindo que, dentro do grupo de usuários com acesso ao compartilhamento, apenas

alguns tenham permissão para alterar os arquivos, como em:

[arquivos]

path = /mnt/arquivos

writable = no

valid users = +arquivos

write list = maria

Nesse caso, usamos a opção "writable = no", que faz com que o compartilhamento passe a ser somente-

leitura. A seguir, especificamos que os usuários do grupo "arquivos" devem ter acesso (somente-leitura) e

usamos a opção "write list = maria" para criar uma exceção, dizendo que a maria pode escrever na pasta.

É importante notar que, neste exemplo, a maria deve fazer parte do grupo "arquivos", caso contrário

Page 30: Tutoriais Linux

teríamos uma situação interessante, onde ela não consegue alterar os arquivos no compartilhamento, pois

não tem acesso a ele em primeiro lugar. :)

Caso a maria não estivesse cadastrada no grupo, você deveria incluir o login na opção "valid users", como

em:

[arquivos]

path = /mnt/arquivos

writable = no

valid users = +arquivos, maria

write list = maria

Podemos também fazer o oposto, restringindo a escrita para alguns usuários, mas mantendo o acesso

para todos os demais. Nesse caso, usamos a opção "read list" para criar uma lista de exceções, como

em:

[arquivos]

path = /mnt/arquivos

writable = yes

valid users = +arquivos, +admin

read list = maria, jose

Nesse exemplo, usamos a opção "writable = yes" e especificamos que os usuários dentro dos grupos

"arquivos" e "admin" tem acesso ao compartilhamento. Em seguida, usamos a opção "read list" para

limitar o acesso dos usuários maria e jose, de forma que eles possam apenas ler, sem alterar os arquivos

dentro da pasta.

Outra opção relacionada é a "read only", que também aceita os valores "yes" e no". Na verdade, ela tem a

mesma função da opção "writable", apenas usa uma lógica invertida. Dizer "writable = yes" ou dizer "read

only = no" tem exatamente o mesmo efeito, como seis e meia-dúzia. Em geral, você usa uma ou outra de

acordo com o contexto, como uma forma de tornar o arquivo mais legível, como em:

[modelos]

path = /mnt/modelos

read only = yes

Continuando, é possível restringir o acesso também com base no endereço IP ou no nome da máquina a

partir da qual o usuário está tentando acessar o compartilhamento. Isso permite adicionar uma camada

extra de segurança no acesso a arquivos importantes, já que além do login e senha, é verificado a partir

de qual máquina o acesso é proveniente.

Isso é feito através das opções "hosts allow" e "hosts deny" que permitem, respectivamente, criar uma

lista de máquinas que podem e que não podem acessar o compartilhamento. As listas podem incluir tanto

os endereços IP quanto os nomes das máquinas.

Para restringir o acesso ao compartilhamento a apenas duas máquinas específicas, você usaria:

[arquivos]

path = /mnt/arquivos

Page 31: Tutoriais Linux

writable = yes

hosts allow = 192.168.1.23, 192.168.1.24

ou

[arquivos]

path = /mnt/arquivos

writable = yes

hosts allow = sparta, athenas

É possível também fazer o inverso, bloqueando o compartilhamento para acessos provenientes das duas

máquinas. Nesse caso, mesmo que o usuário tente acessar usando um login válido, vai receber a

mensagem de acesso negado, como se o login tivesse sido bloqueado ou a senha tenha sido alterada. A

lista não possui um tamanho máximo, você pode incluir quantas máquinas precisar, separando os

endereços ou nomes por vírgula e espaço. Você pode inclusive misturar endereços IP com nomes de

máquinas, como nesse exemplo:

[arquivos]

path = /mnt/arquivos

writable = yes

hosts deny = 192.168.1.23, athenas

É possível ainda combinar a restrição com base nos nomes e endereços com a restrição com base nos

logins de acesso, de forma que o acesso seja autorizado apenas quando as duas condições forem

satisfeitas.

Para permitir que apenas a maria e o joao acessem o compartilhamento e ainda assim apenas se

estiverem usando uma das duas máquinas permitidas, você usaria:

[arquivos]

path = /home/arquivos

writable = yes

valid users = maria, joao

hosts allow = 192.168.1.23, 192.168.1.24

Você pode autorizar ou restringir o acesso para uma faixa inteira de endereços omitindo o último octeto do

endereço. Por exemplo, para que apenas clientes dentro da rede "192.168.1.x" tenham acesso, você

inclui apenas a parte do endereço referente à rede, omitindo o octeto referente ao host, como em:

[arquivos]

path = /mnt/arquivos

writable = yes

hosts allow = 192.168.1.

Se precisar criar exceções, limitando o acesso a algumas máquinas dentro da faixa de endereços

especificada, você pode usar a opção "EXCEPT" para especificar as exceções, como em:

[arquivos]

path = /mnt/arquivos

Page 32: Tutoriais Linux

writable = yes

hosts allow = 192.168.1. EXCEPT 192.168.1.23, 192.168.1.24

Com isso, todos os endereços dentro da faixa teriam acesso, com exceção do .23 e do .24. O mesmo

pode ser feito ao usar a opção "hosts deny", como em:

[restrito]

path = /mnt/sda2/restrito

writable = yes

valid users = isac

hosts deny = 192.168.1. EXCEPT 192.168.1.23

Aqui a lógica é invertida e todos os hosts dentro da faixa de endereços são bloqueados, com exceção

do .23, que passa a ser o único aceito pelo .

Outro parâmetro que pode ser usado ao criar exceções é o "ALL", que inclui todos os endereços

possíveis. Se a idéia é que apenas um determinado endereço possa acessar o compartilhamento, uma

opção é usar "hosts deny = ALL EXCEPT 192.168.1.34".

O default do Samba é permitir o acesso a partir de qualquer máquina, de forma que se você não usar nem

a opção "hosts allow", nem a "hosts deny", qualquer máquina poderá acessar o compartilhamento.

Ao usar apenas a opção "hosts allow", apenas as máquinas listadas terão acesso ao compartilhamento,

as demais serão recusadas. Ao usar apenas a opção "hosts deny", apenas as máquinas listadas não

terão acesso ao compartilhamento (as demais continuam acessando).

Ao combinar o uso das opções "hosts allow" e "hosts deny", a opção "hosts allow" tem precedência (não

importa a ordem em que elas sejam colocadas), de forma que as máquinas listadas terão acesso, mesmo

que ele seja negado pela opção "hosts deny". Por exemplo, ao usar:

[isos]

path = /mnt/isos

hosts allow = 192.168.1.

hosts deny = 192.168.1.43

comment = Algo está errado

... o host "192.168.1.43" continuará tendo acesso ao compartilhamento, pois faz parte da faixa de

endereços cujo acesso é autorizado pela opção "hosts allow". Neste caso, o Samba não considera a

opção "hosts deny = 192.168.1.43" como uma exceção, mas sim como um erro de configuração. Para

bloquear a máquina, você deveria usar:

[isos]

path = /mnt/isos

hosts allow = 192.168.1. EXCEPT 192.168.1.43

comment = Agora sim

Em situações onde você precisa restringir temporariamente o acesso a um determinado compartilhamento

(para alguma tarefa de manutenção, por exemplo) você pode usar a opção "available = no", como em:

Page 33: Tutoriais Linux

[arquivos]

path = /home/arquivos

writable = yes

valid users = maria, joao

available = no

Ela faz com que o compartilhamento "desapareça", da mesma forma que se você apagasse ou

comentasse a configuração. A principal vantagem é que ao apagar você precisaria escrever tudo de novo

para reativar o compartilhamento, enquanto ao usar o "available = no" você precisa apenas remover a

opção ou mudar para "available = yes".

Outra opção interessante que pode ser incluída é a "browseable = no", que transforma o

compartilhamento em um compartilhamento oculto:

[arquivos]

path = /home/arquivos

writable = yes

browseable = no

Com isso, ele não aparece mais no ambiente de redes, mas pode ser acessado normalmente se você

especificar o nome manualmente ao mapear o compartilhamento:

Essa não é propriamente uma opção de segurança, mas pode ser usada para afastar os curiosos dos

compartilhamentos com acesso restrito.

Concluindo, muitas opções que ficam disponíveis no Swat podem ser omitidas ao configurar

manualmente, simplesmente porque são o default no Samba. O próprio Swat evita incluir opções

redundantes ao gerar o arquivo, incluindo apenas as configurações que são diferentes dos valores default.

Não é necessário incluir opções como "writable =no", "available = yes" ou "browseable = yes" no arquivo,

pois estes já são os valores usados por padrão no Samba. Apesar disso, usá-los também não atrapalha

Page 34: Tutoriais Linux

em nada, de forma que nada impede que você os inclua no arquivo para se lembrar mais facilmente das

opções.

Outra dica é que você pode verificar a qualquer momento quais usuários e quais máquinas estão

acessando compartilhamentos no usando o comando "smbstatus, como em:"

# smbstatussmb.conf Modelo

Em [global]#nome do grupo de trabalhoworkgroup = casa#Como a máquina Linux irá aparecer na rede Windowsnetbios name = (está linha pode ser adicionada a baixo do workgroup)####### Authentication ########Modo de acesso aos arquivos do Linuxsecurity = "share" ou "user" (caso exista, remova o ; que está no início desta linha)#share = para NÃO exigir autenticação#user = para exigir autenticaçãoex: security = user

Agora adicione estas linhas no final do arquivo:

#nome do compartilhamento[arquivos]# descrição do compartilhamentocomment = meus arquivos# caminho da pasta, no Linux, que será compartilhadapath = /media/hdb5 #(Informe o caminho da pasta que você que quer compartilhar, pode ser /home/voce)#se todos os compartilhamentos poderão ser acessados por todos os usuáriospublic = yes# se o compartilhamento será visivel ou oculto na rede (yes para visível)browseable = yes# se permitirá escritawritable = yes# somente leituraread only = no# define a mascara em que os arquivos serão criadoscreate mask = 0700 #(terão a permissão rwx somente para o root)# define a mascara em que os diretórios serão criadosdirectory mask = 0700

Salve o arquivo de configuração, e execute este comando para reiniciar o samba$ sudo /etc/inti.d/samba restart

Caso tenha colocado security = user, no momento que for acessar por uma máquina Windows será exibido uma tela de login e senha. Para cadastrar esta senha no linux execute os seguintes comandos.

Configurando uma VPN

Page 35: Tutoriais Linux

O primeiro passo é instalar o OpenVPN, tanto no cliente quanto no . Nas distribuições derivadas

do Debian você pode instalá-lo rapidamente via apt-get:

# apt-get install openvpn

No final da instalação, ele exibirá uma mensagem, perguntando se o OpenVPN deve ser desativado antes

de ser atualizado ("Would you like to stop openvpn before it gets upgraded?"). Responda que sim.

No OpenSuSE, abra o Yast e, dentro da seção de gerenciamento de pacotes, faça uma busca pelo

pacote "openvpn". A busca resulta em dois resultados: "openvpn", que é o pacote em que estamos

interessados e "openvpn-devel", que contém o código fonte. Basta selecionar o pacote e concluir a

instalação.

No Fedora, a instalação pode ser feita usando o yum. Ele se encarregará de instalar também os pacotes

"openssl" e "lzo", que contém as bibliotecas usadas pelo OpenVPN para encriptar e compactar o tráfego

da rede:

# yum install openvpn

No CentOS, é necessário adicionar o repositório do RPMForge já que (até o CentOS 5.1), o pacote

OpenVPN não faz parte dos repositórios oficiais. Você pode adicionar o repositório seguindo as instruções

disponíveis aqui: http://wiki.centos.org/Repositories/RPMForge.

O primeiro passo é instalar a chave GPG do repositório:

# rpm --import http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt

Com a chave instalada, baixe o pacote RPM do repositório. Este pacote instala o arquivo com a

configuração do repositório dentro da pasta "/etc/yum/repos.d". Verifique o link do pacote para a versão

do CentOS que está utilizando na página com as instruções. No caso do CentOS 5.1, versão 32 bits, por

exemplo, o pacote é o "rpmforge-release-0.3.6-1.el5.rf.i386.rpm". Se você está fazendo a configuração via

linha de comando, pode baixar o pacote usando o wget, como em:

# wget -c

http://apt.sw.be/redhat/el5/en/i386/RPMS.dag/rpmforge-release-0.3.6-1.el5.rf.i386.rpm

Em seguida, instale o pacote usando o comando "yum localinstall", como em:

# yum localinstall rpmforge-release-0.3.6-1.el5.rf.i386.rpm

A partir daí, você pode instalar o pacote do OpenVPN usando o yum, assim como no Fedora:

# yum install openvpn

No Mandriva, basta instalar o pacote "openvpn" usando urpmi. Assim como no Fedora, ele também se

encarrega de instalar as dependências:

# urpmi openvpn

Se você estiver utilizando uma distribuição que não inclua o pacote nos repositórios, ou se a versão

disponível for muito antiga, você pode também instalar a partir do pacote com o código fonte, disponível

no: http://openvpn.net/index.php/downloads.html

Page 36: Tutoriais Linux

Depois de instalar o pacote, o próximo passo é carregar o módulo "tun" do Kernel, que é utilizado pelo

OpenVPN para criar interfaces virtuais. Cada VPN criada se comporta como se fosse uma nova interface

de rede, conectada à rede de destino. Imagine que a VPN se comporta como se existisse um cabo de

rede gigante ligando esta interface virtual à rede do outro lado do túnel.

# modprobe tun

Adicione a linha "tun" no final do arquivo "/etc/modules" para que o módulo passe a ser carregado

automaticamente durante o boot:

# echo tun >> /etc/modules

Estes três passos, ou seja, a instalação do OpenVPN, o carregamento do módulo e a adição da linha no

final do arquivo devem ser executados tanto no quanto nos clientes.

Depois de concluída a instalação, você pode criar um túnel simples, não encriptado, usando os comandos

abaixo. Este túnel não pode ser considerado uma "VPN" já que não é seguro, mas serve como um "hello

word" dentro da configuração do OpenVPN.

Presumindo que as duas máquinas estejam ligadas em rede e que não exista nenhum firewall no

caminho, use o comando abaixo no cliente, especificando o endereço do :

# openvpn --remote 192.168.1.1 --dev tun0 --ifconfig 10.0.0.1 10.0.0.2

Faça o mesmo no , especificando agora o endereço do cliente:

# openvpn --remote 192.168.1.202 --dev tun0 --ifconfig 10.0.0.2 10.0.0.1

Rode o comando "ifconfig" no cliente e você verá que foi criada uma interface de rede virtual, a "tun0",

com o endereço "10.0.0.1":

No exemplo, o recebe o endereço "10.0.0.2". Você pode testar a conectividade usando o ping ou

qualquer outra ferramenta:

Page 37: Tutoriais Linux

Como comentei, o OpenVPN possui também uma versão Windows, que está disponível

no http://openvpn.se.

Esta versão inclui um instalador gráfico e funciona em todas as versões do Windows a partir do Windows

2000. Ela inclui também o driver tun/tap, que é instalado automaticamente, você precisa apenas prestar

atenção nas mensagens de instalação. Em um certo ponto, será exibida uma mensagem avisando que o

driver TAP/Win32 não passou pelo processo de certificação de compatibilidade com o Windows.

Responda "Continuar assim mesmo" para efetuar a instalação, do contrário o OpenVPN não funcionará.

Chaves esatáticas

A forma mais simples de configurar o OpenVPN é utilizar chaves estáticas, onde um arquivo contendo um

algoritmo de encriptação é usado pelas duas partes para encriptar os dados transmitidos através da VPN.

Page 38: Tutoriais Linux

Nesse modo, você gera uma arquivo de texto no , contendo a chave de encriptação e precisa apenas

copiá-la para o cliente e fazer uma configuração rápida para criar a VPN. Se você quer apenas criar uma

VPN doméstica, ou criar uma VPN temporária entre duas redes, esta é a configuração recomendada.

O grande problema em utilizar uma chave estática é que, como o nome sugere, a mesma chave é

utilizada sessão após sessão, sem nunca mudar. Com isso, existe uma pequena possibilidade de um

atacante obstinado conseguir quebrar a VPN usando um ataque de força bruta. Como a chave é um

arquivo de texto, que é armazenado tanto no cliente quanto no , existe também a possibilidade de alguém

conseguir copiá-lo, caso tenha acesso físico a uma das máquinas. Outra limitação é que usando uma

chave estática o suportará a conexão de um único cliente por VPN.

Para VPNs com vários clientes, ou em redes empresariais, onde a segurança é prioridade, é

recomendável utilizar uma estrutura baseada em certificados X509, como veremos no tópico seguinte.

Vamos então à configuração de nossa primeira VPN. Para este exercício inicial, recomendo que utilize

duas máquinas da rede local, que não tenham firewall ativo. Depois de entender melhor como o sistema

funciona, passaremos para uma configuração mais elaborada.

O primeiro passo é gerar o arquivo com a chave, no . O arquivo deve ser gerado dentro do diretório

"/etc/openvpn" (o diretório padrão de configuração), de forma que acessamos o diretório antes de

executar o comando que gera a chave:

# cd /etc/openvpn

# openvpn --genkey --secret static.key

Isso gerará o arquivo "static.key", que contém a chave de encriptação que será usada para criar a

conexão. Ele é um arquivo de texto simples, que contém uma chave de 2048 bits, como em:

#

# 2048 bit OpenVPN static key

#

-----BEGIN OpenVPN Static key V1-----

0600d007988a59c6f7895884d336d445

2679fd3d2c0b9e0b777b4da92ab97043

... (mais 13 linhas)

e871ed9077185a2a6904e67cd0869e15

-----END OpenVPN Static key V1-----

Este arquivo deve ser copiado para a pasta "/etc/openvpn" do cliente, usando (por exemplo) o SFTP.

Você pode usar também um pendrive, ou outra mídia de uso local, mas não é recomendável enviá-lo por

meios não seguros (e-mail por exemplo), já que qualquer um que tenha acesso ao arquivo poderá se

conectar à sua VPN ou desencriptar todo o tráfego transmitido através dela.

Para acessar o (a partir do cliente) via SFTP, use o comando "sftp ip" para se conectar e, em seguida,

use os comandos "cd /etc/openvpn" e "get static.key" para fazer a cópia, como em:

# cd /etc/openvpn

# sftp [email protected]

Page 39: Tutoriais Linux

Password:

sftp> cd /etc/openvpn

sftp> get static.key

Fetching /etc/openvpn/static.key to static.key

sftp> quit

Com o arquivo contendo a chave presente nas duas máquinas, falta criar os arquivos de configuração que

serão usados pelo OpenVPN. Neste exemplo, criarei o arquivo "/etc/openvpn/server.conf" no e o arquivo

"/etc/openvpn/client.conf" no cliente. Os nomes podem ser diferentes, mas os arquivos devem ser criados

dentro da pasta "/etc/openvpn" e devem terminar com a extensão ".conf"

O arquivo "/etc/openvpn/server.conf", no , fica com o seguinte conteúdo:

dev tun

ifconfig 10.0.0.1 10.0.0.2

secret static.key

A linha "ifconfig 10.0.0.1 10.0.0.2" inclui os endereços que serão usados pelas interfaces virtuais da VPN,

no e no cliente. No exemplo, o utilizará o endereço "10.0.0.1" e o cliente o endereço "10.0.0.2". Você

pode utilizar outros endereços se preferir. O importante é que os endereços utilizados na VPN devem ser

sempre diferentes dos endereços usados na rede local.

A linha "secret static.key" especifica o arquivo com a chave de encriptação, que criamos no passo

anterior. Não esqueça de alterar a linha caso o nome do arquivo seja diferente.

Em seguida, vem o arquivo "/etc/openvpn/client.conf", que deve ser criado no cliente:

remote 192.168.1.101

dev tun

ifconfig 10.0.0.2 10.0.0.1

secret static.key

A primeira linha especifica o endereço IP do . No exemplo, estou utilizando um endereço de rede local, já

que estamos apenas testando a VPN, mas, em um exemplo real de uso, você utilizaria o endereço IP de

Internet do ou (ao utilizar uma conexão com IP dinâmico) um domínio virtual utilizado por ele. Se você

ainda não tem um, acesse o no-ip.com ou o dyndns.org e faça o registro.

Com os arquivos de configuração criados, inicializar a VPN é incrivelmente simples. Você precisa apenas

reiniciar o serviço "openvpn" tanto no cliente quanto no , usando o comando:

# /etc/init.d/openvpn restart

Ao ser iniciado, o serviço procura por arquivos ".conf" dentro do diretório "/etc/openvpn" e inicia as VPNs

configuradas automaticamente (desde que o serviço esteja configurado para subir durante o boot, o que é

feito por padrão na maioria das distribuições). Isso não apenas simplifica a configuração, mas faz com que

a VPN passe a ser automaticamente restabelecida a cada boot. Para desativá-la, basta parar o serviço:

# /etc/init.d/openvpn stop

Page 40: Tutoriais Linux

Você pode, também, ativar o OpenVPN manualmente, usando (como root) o comando:

# openvpn --config /etc/openvpn/client.conf

(onde o "client.conf" é o arquivo de configuração que será usado)

Este comando manual permite acompanhar as mensagens de inicialização e de conexão, o que ajuda a

descobrir o que está errado em casos em que a VPN não funciona, embora a configuração pareça estar

correta.

Se a VPN é usada pelos clientes apenas esporadicamente, você pode criar um ícone no desktop, ou um

pequeno script contendo o comando, para que o usuário possa se conectar à VPN apenas quando

precisar. Outra opção é instalar o kvpnc (http://home.gna.org/kvpnc/), um cliente gráfico que pode ser

usado para se conectar a VPNs baseadas em diversos protocolos, incluindo o OpenVPN:

Depois de estabelecida a VPN, o cliente passará a ter uma nova interface de rede, a "tun0", com o

endereço IP "10.0.0.2", que funciona como um link ponto-a-ponto com a interface "tun0" do , que recebe o

endereço "10.0.0.1":

Teste a conexão usando o ping, ou acessando algum serviço disponível no , como em:

# ssh 10.0.0.1

Depois do teste inicial, você pode fazer um teste realizando a conexão via Internet (você pode usar uma

conexão discada ou outra conexão temporária no cliente para fazer o teste). Para isso, você vai precisar

apenas alterar a configuração no cliente, adicionando o endereço de internet do , como em:

remote guiadohardware.no-ip.org

dev tun

ifconfig 10.0.0.2 10.0.0.1

secret static.key

Não se esqueça de reiniciar o OpenVPN para que a alteração entre em vigor:

# /etc/init.d/openvpn restart

o teriam tantas falhas e brechas de segurança.

Page 41: Tutoriais Linux

Estabilizando e otimizando a conexão

Usando a configuração simplificada do exemplo anterior, você notará que a VPN não será muito estável,

pois qualquer interrupção na comunicação entre as duas máquinas derrubará o link, até que você reinicie

o serviço do OpenVPN (no cliente), forçando a reconexão, como em:

# /etc/init.d/openvpn restart

Vamos então a um conjunto de parâmetros de configuração que permitem estabilizar a VPN, fazendo com

que o OpenVPN passe a monitorar a conexão e restabelecê-la automaticamente sempre que necessário.

O primeiro, e mais importante, é o parâmetro "keepalive", que faz com que o e o cliente monitorem a

conexão, enviando pings periódicos um para o outro, e reiniciem a VPN automaticamente caso não

recebam resposta dentro de um período determinado. Esta opção é especialmente importante em VPNs

usadas através de links ADSL ou qualquer outro tipo de conexão que não seja completamente estável.

Um exemplo de uso seria:

keepalive 10 120

O primeiro número especifica o intervalo dos pings e o segundo o timeout, depois do qual a VPN é

reiniciada. Nesse caso, o ping é enviado a cada 10 segundos sem atividade e a VPN é reiniciada depois

de 120 segundos sem respostas. Caso o link seja interrompido, o cliente tenta restabelecer a VPN

periodicamente, até que tenha sucesso. Esta linha deve ser incluída tanto na configuração do quanto na

do cliente.

Opcionalmente, você pode incluir a linha "inactive", para especificar um tempo máximo para as tentativas

de reconexão. Se quiser que o cliente desista depois de uma hora, por exemplo, inclua a linha:

inactive 3600

O parâmetro "comp-lzo" faz com que o OpenVPN passe a compactar os dados transmitidos através do

túnel (é necessário que o pacote "lzo" esteja instalado). O algoritmo usado pelo OpenVPN é bastante

leve, por isso o uso adicional de processamento, tanto no quando nos clientes é pequeno. A compressão

dos dados não faz milagres, mas é uma boa forma de melhorar o desempenho da VPN ao utilizar links

lentos ou congestionados. Esta é outra opção que deve ser incluída tanto no quanto nos clientes para

que seja usada:

comp-lzo

Outras duas opções, úteis para tornar a VPN mais confiável e mais resistente a problemas de

conectividade, são a "persistkey" e a "persisttun". Elas fazem com que o daemon mantenha a interface

tun aberta e as chaves carregadas quando é reiniciado (quando a VPN é restabelecida depois de uma

queda de conexão, por exemplo), o que torna mais rápida a restauração do link e evita problemas

diversos:

persistkey

persisttun

Outra opção útil ao utilizar conexões com IP dinâmico é a opção "float", que permite que o túnel continue

aberto mesmo que o endereço IP da outra máquina mude. Em situações normais, a mudança de IP faria

com que a conexão fosse encerrada e o túnel fosse interrompido até que fosse reiniciado (seja

manualmente ou seja pelo uso da opção keepalive). A opção "float" torna o processo mais transparente, já

Page 42: Tutoriais Linux

que o OpenVPN passa a monitorar as mudança de endereços, mantendo o túnel aberto enquanto houver

conexão entre as duas partes. Essa opção também deve ser incluída tanto na configuração do quanto na

do cliente:

float

Temos aqui um exemplo mais incrementado de configuração do , onde a porta é especificada

manualmente e são usados os parâmetros que acabamos de ver:

dev tun

proto udp

port 22222

keepalive 10 120

comp-lzo

persistkey

persisttun

float

ifconfig 10.0.0.1 10.0.0.2

secret static.key

A configuração no cliente é praticamente a mesma, com a adição da linha "remote", que especifica o

endereço do e a mudança na linha "ifconfig", onde a ordem dos endereços são trocados:

remote guiadohardware.no-ip.org

dev tun

proto udp

port 22222

keepalive 10 120

comp-lzo

persistkey

persisttun

float

ifconfig 10.0.0.2 10.0.0.1

secret static.key