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

1 -Configurando o usário root:
criar uma senha para o root

sudo 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 eth0
iface eth0 inet dhcp
.... pelo texto
auto eth0
iface eth0 inet static
address 192.168.1.10
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1
2 - Especifique os servidores de DNS

sudo nano /etc/resolv.conf
nameserver 192.168.1.10
3- Reinicie a rede do servidor

sudo /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 squid
Toda 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
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.orig
Em seguida, crie um novo arquivo "/etc/squid/squid.conf", contendo apenas as quatro linhas abaixo:
http_port 3128
visible_hostname server
acl all src 0.0.0.0/0.0.0.0
http_access allow all
Estas 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 restart
Se estiver no CentOS, Fedora ou Mandriva, pode utilizar o comando "service", que economiza alguns
toques no teclado:
# service squid restart
No 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 3128
visible_hostname servidor
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 563 # https, snews
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl Safe_ports port 901 # swat
acl Safe_ports port 1025-65535 # portas altas
acl purge method PURGE
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
acl redelocal src 192.168.1.0/24
http_access allow localhost
http_access allow redelocal
http_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 3128
acl all src 0.0.0.0/0.0.0.0
acl Safe_ports port 21 80 443 563 70 210 280 488 59 777 901 1025-65535
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:
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:
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:

http_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.com
always_direct allow site
Esta regra deve vir antes da regra que libera os acessos provenientes da rede local, como em:
acl site dstdomain siteproblematico.com
always_direct allow site
Depois de configurar o arquivo, não se esqueça de reiniciar o serviço para que a configuração entre em
vigor:
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:

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 KB
3- 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 MB
minimum_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 90
cache_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
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% 2280
refresh_pattern ^gopher: 15 0% 2280
refresh_pattern . 15 20% 2280
Depois de adicionar todas estas configurações, o nosso arquivo de configuração já ficará bem maior:
http_port 3128
cache_mem 64 MB
cache_swap_low 90
cache_swap_high 95
acl all src 0.0.0.0/0.0.0.0
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.br
http_access deny bloqueados
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
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.br
www.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"
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 permitidos
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.45
http_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.99
google.com A 64.233.187.99
google.com A 64.233.167.99
Depois de adicionar as novas regras, nosso arquivo de configuração ficaria assim:

http_port 3128
error_directory /usr/share/squid/errors/Portuguese/
cache_mem 64 MB
cache_swap_low 90
cache_swap_high 95
acl all src 0.0.0.0/0.0.0.0
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:
orkut
xxx
sexo
teens
warez
... 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.
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%252F
www.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:
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:00
http_access deny madrugada
acl almoco time 12:00-14:00
http_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:
http_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:
http_access allow almoco
acl extban url_regex -i "/etc/squid/extban"
http_access deny extban
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 orkut dstdomain orkut.com www.orkut.com
http_access allow orkut almoco
http_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:

delay_pools 1
delay_class 1 2
delay_parameters 1 114688/114688 16384/16348
delay_access 1 allow redelocal
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.2
http_access allow chefe
delay_pools 1
delay_class 1 2
delay_parameters 1 114688/114688 16384/16348
delay_access 1 allow redelocal
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.2
http_access allow chefe
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 \.torrent
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"
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
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:
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-utils
No 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_passwd
O 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 servidor
Depois de terminar de cadastrar os usuários, adicione as linhas que ativam a autenticação no squid.conf:
auth_param basic realm Squid
auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/squid_passwd
acl autenticados proxy_auth REQUIRED
http_access allow autenticados
O "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:
... 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:
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:
# Autentica o usuário:
# Libera o acesso da rede local e do localhost para os autenticados,
# bloqueia os demais:
Veja 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:
acl permitidos proxy_auth servidor tux
http_access allow permitidos
http_access allow autenticados almoco
Aqui 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):
authenticate_ip_ttl 5 minutes
auth_param basic program /usr/lib/squid/smb_auth -W dominio -U 192.168.1.254
Com 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
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 virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_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:
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.STABLE2
configure 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.
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:
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:
Restarting Squid HTTP proxy: squid* Creating squid spool directory structure
2008/06/31 16:35:46| Creating Swap Directories
FATAL: Failed to make swap directory /mnt/sda2/squid/00: (13) Permission denied
Squid Cache (Version 2.6.STABLE5): Terminated abnormally.
CPU Usage: 0.000 seconds = 0.000 user + 0.000 sys
Maximum Resident Size: 0 KB
Page 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 /mnt/sda2/squid 5120 16 256
cache_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
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 on
O 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
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 restart
ou:
# 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.4
Copyright 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:db
Sending on LPF/eth1/00:15:00:4b:68:db
Sending on Socket/fallback
DHCPREQUEST on eth1 to 255.255.255.255 port 67
DHCPACK from 192.168.1.1
bound 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ê.
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.
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
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.
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
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
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
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:
# 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:
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]
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.
# 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]
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]
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]
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]
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]
writable = yes
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]
writable = no
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
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]
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]
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]
writable = yes
hosts allow = 192.168.1.23, 192.168.1.24
ou
[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]
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]
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]
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:
[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]
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
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:"
# smbstatus
smb.conf Modelo
Em [global]
#nome do grupo de trabalho
workgroup = casa
#Como a máquina Linux irá aparecer na rede Windows
netbios name = (está linha pode ser adicionada a baixo do workgroup)
####### Authentication #######
#Modo de acesso aos arquivos do Linux
security = "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ção
ex: security = user
Agora adicione estas linhas no final do arquivo:
#nome do compartilhamento
[arquivos]
# descrição do compartilhamento
comment = meus arquivos
# caminho da pasta, no Linux, que será compartilhada
path = /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ários
public = yes
# se o compartilhamento será visivel ou oculto na rede (yes para visível)
browseable = yes
# se permitirá escrita
writable = yes
# somente leitura
read only = no
# define a mascara em que os arquivos serão criados
create mask = 0700 #(terão a permissão rwx somente para o root)
# define a mascara em que os diretórios serão criados
directory 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

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
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:
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.
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 root@192.168.1.101
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
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:
o teriam tantas falhas e brechas de segurança.
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:
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á
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

Tutoriais Linux

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Tutoriais Linux

Transféré par

Droits d'auteur :

Formats disponibles

Tutoriais Linux

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

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

criar uma senha para o 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....

2 - Especifique os servidores de DNS

3- Reinicie a rede do servidor

2 -Configurando um servidor proxy com o Squid

Criando uma configuração básica

Se você adicionasse algo como:

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

Nas versões recentes do Squid, ao bloquear um domínio é automaticamente bloqueado também o

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

... e adicione a regra abaixo, contendo a localização do arquivo:

Gerenciando o uso da banda

Neste caso, a parte final do arquivo de configuração ficaria:

Configurando um proxy transparente

Configurando um servidor DHCP

Nas distribuições derivadas do Debian, o pacote correspondente ao DHCP se chama "dhcp3-server" e

... e adicione a placa que o DHCP deve escutar, como em:

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

Configurando Servidor Samba

Pacote Debian Fedora

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

# apt-get install samba smbclient swat samba-doc

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

Com os pacotes instalados, use os comandos:

# 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:

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

server string = Samba

Duas dicas são que:

Unknown parameter encountered: "wrritable"

# chmod 777 /mnt/arquivos

# adduser joao arquivos

# deluser joao arquivos

# chgrp arquivos /mnt/arquivos

# chgrp -R arquivos /mnt/arquivos

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

Agora adicione estas linhas no final do arquivo:

Salve o arquivo de configuração, e execute este comando para reiniciar o samba

Configurando uma VPN

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

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

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

# yum install openvpn

# echo tun >> /etc/modules

# 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

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

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

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

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

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

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