Principais tipos de redes sem fio incluem:
| Cellular Digital Packet Data | ||
| High Speed Circuit de dados comutados | | |
| Packet dados celulares | ||
| General Packet Radio Service | ||
| 1x transmissão via rádio tecnologia | ||
| | ||
| | ||
| MMDS | ||
| Local Multipoint Distribution Service | ||
| Interoperabilidade mundial para acesso microondas | ||
| Wi-Fi | ||
| | | |
Access Point
Access Point ou AP ,
Pontos de acesso Wi-Fi estão se tornando populares. Muitos estabelecimentos comerciais que oferecem o acesso a internet através de um ponto de acesso como serviço ou cortesia aos clientes, tornando-se hotspots. Também é prático pois a implantação de uma rede sem fio interligada por um ponto de acesso economiza o trabalho de instalar a infra-estrutura cabeada.
Vários pontos de acesso podem trabalhar em conjunto para prover um acesso em uma área maior. Esta área é subdividida e áreas menores sendo cada uma delas coberta por um ponto de acesso, provendo acesso sem interrupções ao se movimentar entre as áreas através de roaming. Também pode ser formada uma rede ad-hoc onde os dispositivos móveis passam a agir intermediando o acesso dos dispositivos mais distantes ao ponto de acesso caso ele não possa alcançá-lo diretamente.
Estes pontos de acesso precisam implementar a segurança da comunicação entre eles e os dispositivos móveis que estão
O que é?
A tecnologia wireless (sem fios) permite a conexão entre diferentes pontos sem a necessidade do uso de cabos - seja ele telefônico, coaxial ou óptico - por meio de equipamentos que usam radiofrequência (comunicação via ondas de rádio) ou comunicação via infravermelho, como em dispositivos compatíveis com IrDA.
Wireless é uma tecnologia capaz de unir terminais eletrônicos, geralmente computadores, entre si devido às ondas de rádio ou infravermelho, sem necessidade de utilizar cabos de conexão entre eles. O uso da tecnologia wireless vai desde transceptores de rádio como walkie-talkies até satélites artificais no espaço.
Seu uso mais comum é em redes de computadores, onde a grande maioria dos usuários utiliza-se da mesma para navegar pela Internet no escritório, em um bar, um aeroporto, um parque, em casa, etc. Uma rede de computadores sem fios são redes que utilizam ondas eletromagnéticas ao invés de cabos, tendo sua classificação baseada na área de abrangência delas: redes pessoais ou curta distância (WPAN), redes locais (WLAN), redes metropolitanas (WMAN) e redes geograficamente distribuídas ou de longa distância (WWAN).
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 servidor proxy (que combina todos os acessos via http) consuma um pouco menos que o total de banda disponível, de forma a sempre deixar um pouco reservado para outros protocolos.
Um link de 1 megabit (1024 kbits) corresponde a 131.072 bytes por segundo. Nas regras do Squid, sempre usamos bytes, por isso lembre-se de fazer a conversão, dividindo o valor em kbits por 8 e multiplicando por 1024 para ter o valor em bytes.
Podemos, por exemplo, limitar a banda total usada pelo Squid a 114.688 bytes por segundo, deixando 128 kbits do link livres para outros protocolos e limitar cada usuário a no máximo 16.384 bytes por segundo, que correspondem a 128 kbits. Nem todos os usuários vão ficar baixando arquivos a todo momento, por isso o valor ideal reservado a cada usuário vai variar muito de acordo com a rede. Você pode acompanhar o uso do link e ir ajustando o valor conforme a utilização.
Neste caso, a parte final do arquivo de configuração ficaria:
acl redelocal src 192.168.1.0/24
delay_pools 1
delay_class 1 2
delay_parameters 1 114688/114688 16384/16348
delay_access 1 allow redelocal
http_access allow localhost
http_access allow redelocal
http_access deny all
A acl "redelocal" está agora condicionada a três novas regras, que aplicam o uso do limite de banda. O acesso continua sendo permitido, mas agora dentro das condições especificadas na linha "delay_parameters 1 114688/114688 16384/16384", onde vão (respectivamente) os valores com a banda total disponível para o Squid e a banda disponível para cada usuário.
Veja que nessa regra limitamos a banda apenas para a acl "redelocal" e não para o "localhost". Isso significa que você continua conseguindo fazer downloads na velocidade máxima permitida pelo link ao acessar a partir do próprio servidor; 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
acl redelocal src 192.168.1.0/24
delay_pools 1
delay_class 1 2
delay_parameters 1 114688/114688 16384/16348
delay_access 1 allow redelocal
http_access allow localhost
http_access allow redelocal
http_access deny all
Esta regra de exceção pode der usada também em conjunto com as demais regras de restrição de acesso que vimos anteriormente. Basta que a acl com o IP liberado seja colocada antes das acls com as restrições de acesso, como em:
acl chefe src 192.168.1.2
http_access allow chefe
acl bloqueados url_regex -i "/etc/squid/bloqueados"
http_access deny bloqueados
acl palavrasproibidas dstdom_regex "/etc/squid/palavrasproibidas"
http_access deny palavrasproibidas
acl redelocal src 192.168.1.0/24
http_access allow localhost
http_access allow redelocal
http_access deny all
Concluindo, mais um tipo de bloqueio útil em muitas situações é com relação a formatos de arquivos. Você pode querer bloquear o download de arquivos .exe ou .sh para dificultar a instalação de programas nas estações, ou bloquear arquivos .avi ou .wmv para economizar banda da rede, por exemplo.
Neste caso, você pode usar a regra a seguir, especificando as extensões de arquivo desejadas. Ela utiliza o parâmetro "url_regex" (o mesmo que utilizamos para criar o bloqueio de domínios), dessa vez procurando pelas extensões de arquivos especificadas:
acl extban url_regex -i \.avi \.exe \.mp3 \.torrent
http_access deny extban
Esta regra aceita também o uso de um arquivo externo, de forma que se a lista começar a ficar muito grande, você pode migrá-la para dentro de um arquivo de texto e especificar sua localização dentro da acl, como em:
acl extban url_regex -i "/etc/squid/extban"
http_access deny extban
Dentro do arquivo, você inclui as extensões desejadas (sem esquecer da barra invertida antes do ponto), uma por linha, como em:
\.avi
\.exe
\.mp3
\.torrent
Uma observação é que bloquear arquivos .torrent usando essa regra não impede que os usuários da rede utilizem o bittorrent, mas apenas que baixem os arquivos .torrent para iniciarem o download (o que acaba sendo o suficiente para fazer os usuários menos técnicos desistirem de baixar o arquivo). Para realmente bloquear o download de arquivos via bittorrent, é necessário bloquear diretamente os endereços dos trackers.
Continuando, sempre que fizer alterações na configuração, você pode aplicar as mudanças usando o comando:
# /etc/init.d/squid reload
Evite usar o "/etc/init.d/squid restart" em ambientes de produção, pois ele força um reinício completo do Squid, onde o proxy precisa finalizar todas as conexões abertas, finalizar todos os processos e desativar o cache, para só então ler a configuração e carregar todos os componentes novamente. Isso faz com que o proxy fique vários segundos (ou até minutos, de acordo com o número de clientes conectados a ele) sem responder conexões, fazendo com que o acesso fique fora do ar:
# /etc/init.d/squid restart
Restarting Squid HTTP proxy: squid Waiting.....................done.
O parâmetro "reload" permite que o Squid continue respondendo aos clientes e aplique a nova configuração apenas às novas requisições. Ele é suportado por diversos outros serviços onde o "restart" causa interrupção no serviço, como no caso do Apache.
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 servidores diferentes, o Squid considerará que tratam-se de dois sites diferentes, de forma que ao bloquear apenas o "www.orkut.com" os usuários ainda conseguirão acessar o site através do "orkut.com" e vice-versa. Nesses casos, para bloquear ambos, é preciso incluir as duas possibilidades dentro da regra, como em:
acl bloqueados dstdomain orkut.com www.orkut.com playboy.abril.com.br
http_access deny bloqueados
Você pode incluir quantos domínios quiser dentro da acl, basta separá-los por espaço e deixar tudo na mesma linha. Se a regra começar a ficar muito grande, você tem a opção de transferir as entradas para um arquivo. Nesse caso, crie um arquivo de texto simples, com todos os domínios desejados (um por linha), como em:
orkut.com
www.orkut.com
playboy.abril.com.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"
http_access deny bloqueados
Naturalmente, não seria viável tentar bloquear manualmente todos os sites pornográficos, chats, comunidades online, e todos os outros tipos de sites que não são úteis em um ambiente de trabalho. A idéia seria logar os acessos (com a ajuda do Sarg, que veremos mais adiante) e bloquear os sites mais acessados, conforme tomar conhecimento deles. É sempre uma corrida de gato e rato, mas, em se tratando de pessoas adultas, não há nada que uma boa conversa com o chefe não possa resolver. ;)
De qualquer forma, em alguns ambientes pode ser mais fácil bloquear inicialmente o acesso a todos os sites e ir abrindo o acesso a apenas alguns sites específicos, conforme a necessidade. Neste caso, invertemos a lógica da regra. Criamos um arquivo com sites permitidos, adicionamos a regra que permite o acesso a eles e em seguida bloqueamos o acesso a todos os demais, como neste exemplo:
acl permitidos url_regex -i "/etc/squid/permitidos"
http_access allow permitidos
http_access deny all
Nas versões recentes do Squid, ao bloquear um domínio é automaticamente bloqueado também o endereço IP do servidor 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 servidores 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
visible_hostname gdh
error_directory /usr/share/squid/errors/Portuguese/
cache_mem 64 MB
maximum_object_size_in_memory 64 KB
maximum_object_size 512 MB
minimum_object_size 0 KB
cache_swap_low 90
cache_swap_high 95
cache_dir ufs /var/spool/squid 2048 16 256
cache_access_log /var/log/squid/access.log
refresh_pattern ^ftp: 15 20% 2280
refresh_pattern ^gopher: 15 0% 2280
refresh_pattern . 15 20% 2280
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 21 80 443 563 70 210 280 488 59 777 901 1025-65535
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 bloqueados url_regex -i "/etc/squid/bloqueados"
http_access deny bloqueados
acl redelocal src 192.168.1.0/24
http_access allow localhost
http_access allow redelocal
http_access deny all
Veja que coloquei as duas regras antes do "http_access allow redelocal", que abre tudo para a rede local. Como o Squid processa as regras seqüencialmente, as páginas que forem bloqueadas pela acl "bloqueados" não chegam a passar pela regra que autoriza os acessos provenientes da rede local.
Uma segunda possibilidade é usar o parâmetro "dstdom_regex", que permite bloquear sites de uma forma mais geral, com base em palavras incluídas na URL de acesso. Você pode bloquear todas as páginas cujo endereço inclua a palavra "sexo" ou "orkut", por exemplo. Note que, ao usar esta regra, o Squid verifica a existência das palavras apenas na URL do site e não no conteúdo da página. Para criar filtros baseados no conteúdo, você pode utilizar o DansGuardian, que veremos mais adiante.
Crie mais um arquivo de texto, contendo as palavras que devem ser bloqueadas, uma por linha, como em:
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:
acl bloqueados url_regex -i "/etc/squid/bloqueados"
http_access deny bloqueados
acl palavrasproibidas dstdom_regex "/etc/squid/palavrasproibidas"
http_access deny palavrasproibidas
acl redelocal src 192.168.1.0/24
http_access allow localhost
http_access allow redelocal
http_access deny all
Incluídas as regras, os clientes passam a ver uma mensagem de erro ao tentar acessar páginas que se enquadrem nos bloqueios:
Por padrão, as mensagens de erro aparecerem
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.
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 servidor;
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 servidor é sempre muito menor do que o espaço
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 servidor não dedicado, que atende a apenas alguns micros (como o servidor de uma pequena rede local) e até 1/3 da memória RAM total em um servidor proxy dedicado, que atende a um volume maior de usuários (veja mais detalhes a seguir). Em um servidor 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
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 servidor 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
visible_hostname gdh
cache_mem 64 MB
maximum_object_size_in_memory 64 KB
maximum_object_size 512 MB
minimum_object_size 0 KB
cache_swap_low 90
cache_swap_high 95
cache_dir ufs /var/spool/squid 2048 16 256
cache_access_log /var/log/squid/access.log
refresh_pattern ^ftp: 15 20% 2280
refresh_pattern ^gopher: 15 0% 2280
refresh_pattern . 15 20% 2280
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 21 80 443 563 70 210 280 488 59 777 901 1025-65535
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
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 servidor 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 servidor que precise ser configurado de forma minimamente segura. Naturalmente, você pode adicionar outras portas à lista, conforme necessário.
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 gdh
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
visible_hostname gdh
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 21 80 443 563 70 210 280 488 59 777 901 1025-65535
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
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 servidor), e a acl "rede local", que inclui os demais micros da rede local. Substitua o "192.168.1.0/24" pela faixa de endereços IP e a máscara de sub-rede usada na sua rede local (o 24 equivale à mascara 255.255.255.0).
Depois de criadas as duas políticas de acesso, vão duas linhas no final do arquivo que especificam que os micros que se enquadrarem nelas poderão usar o proxy:
http_access allow localhost
http_access allow redelocal
Lembra-se da acl "all", que contém todo mundo? Vamos usá-la para especificar que os clientes que não se enquadrarem nas duas regras acima (ou seja, clientes não-autorizados, vindos da Internet) não poderão usar o proxy:
http_access deny all
Esta linha deve ir no final do arquivo, depois das outras duas. A ordem é importante, pois o Squid interpreta as regras na ordem em que são colocadas no arquivo. Se você permite que o micro X acesse o proxy, ele acessa, mesmo que uma regra mais abaixo diga que não.
Se você adicionasse algo como:
acl redelocal src 192.168.1.0/24
http_access allow redelocal
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 servidor proxy propriamente dito, mas, de qualquer forma, você pode solucionar o problema de forma muito simples orientando o servidor 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
acl redelocal src 192.168.1.0/24
http_access allow localhost
http_access allow redelocal
http_access deny all
Depois de configurar o arquivo, não se esqueça de reiniciar o serviço para que a configuração entre em vigor:
# /etc/init.d/squid restart
Nesse ponto o seu proxy já está completamente funcional. Você pode começar a configurar os navegadores nos PCs da rede local para utilizá-lo e acompanhar o desempenho da rede.
O 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 gdh
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 gdh: 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 "gdh" 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
O que é?
O proxy serve como um intermediário entre os PCs de uma rede e a Internet. Um servidor proxy pode ser usado com basicamente três objetivos:
1- Compartilhar a conexão com a Internet quando existe apenas um IP disponível (o proxy é o único realmente conectado à Web, os outros PCs acessam através dele).
2- Melhorar o desempenho do acesso através de um cache de páginas; o proxy armazena as páginas e arquivos mais acessados, quando alguém solicitar uma das páginas já armazenadas do cache, esta será automaticamente transmitida, sem necessidade de baixa-la novamente.
3- Bloquear acesso a determinadas páginas (pornográficas, etc.), como tipo passa pelo proxy é fácil implantar uma lista de endereços ou palavras que devem ser bloqueadas, para evitar por exemplo que os funcionários percam tempo em sites pornográficos em horário de trabalho.
Hoje em dia os servidores proxy são extremamente comuns, mesmo em redes domésticas, não é necessário um PC dedicado a esta função, basta instalar um dos vários programas de servidor proxy disponíveis no PC com a conexão à Internet..
Para testar a instalação do PHP, crie um arquivo qualquer com extensão .php (info.php, por exemplo) na pasta base do seu servidor Web Apache (htdocs) e, dentro dele digite o seguinte código:
http://localhost/info.php
Uma tela com informações sobre a configuração do PHP deverá ser exibida, como indicado abaixo:
Configurando o Apache para trabalhar com o PHP
Para que o servidor Web Apache possa reconhecer o PHP e redirecionar as páginas escritas nesta linguagem para o seu interpretador, precisaremos adicionar algumas configurações no arquivo de configuração do Apache, o httpd.conf, que está localizado na pasta \conf deste servidor Web. Se você não tiver alterado a localização padrão dos arquivos do servidor Web Apache durante a instalação, o caminho completo para este arquivo é o seguinte:
C:\Arquivos de programas\Apache Group\Apache\conf\httpd.conf
Adicione as seguintes linhas NO FINAL deste arquivo:
|
|
Salve este arquivo e, em seguida, pare e re-inicie o Apache. Na janela do Apache, deverá aparecer uma string indicando que o PHP foi carregado juntamente com o servidor Web, como indicado abaixo:
Em plataformas Windows NT/2000, vá para a janela do gerenciador de serviços e pare e re-inicie o serviço do Apache. Nesta janela, no item correspondente à descrição do serviço do Apache, deverá ser exibido uma descrição semelhante a da indicada na figura acima.
Configurando o PHP
Copie o arquivo php.ini-dist, que se encontra na pasta C:\PHP, para a pasta do Windows (geralmente C:\Windows). Renomeie-o para php.ini e em seguida abra-o. Localize o seguinte texto dentro deste arquivo: "extension_dir" e altere o valor desta entrada para o nome da pasta com os arquivos das extensões do PHP, que no nosso caso é "c:\php\extensions". Após a alteração, esta seção do arquivo deverá parecer como a seguir:
Salve e feche este arquivo.
Copie também o arquivo php4ts.dll, que se encontra na pasta C:\PHP, para a pasta C:\Windows\System, no caso de Windows95/98/ME/XP, ou para a pasta C:\WINNT\System32, no caso de WindowsNT/2000.
Obtendo o PHP
Efetue o download do pacote com os arquivos do PHP para Windows, no seguinte endereço:
http://www.php.net/downloads.php
Baixe o arquivo no formato .ZIP,. Este arquivo zipado deverá ter o seguinte nome: php-x.x.x-Win32.zip, onde x.x.x é a versão da linguagem.Descompacte este pacote para uma pasta qualquer no seu disco. Vamos considerar que a pasta de destino dos arquivos seja C:\PHP.
Após a descompactação, a estrutura de diretórios do PHP deve ficar como indicado na figura abaixo:
Para INICIAR o servidor Web Apache, vá no botão Iniciar->Programas->Apache HTTP Server e clique em Start Apache in Console. Uma janela como esta deverá aparecer, indicando que o Apache está em execução:
Instalando o Apache
Para efetuar a instalação a partir deste tipo de arquivo .msi, você deverá ter o utilitário Microsoft Windows Installer instalado no seu sistema. Os usuários do Windows2000, WindowsME e WindowsXP já possuem este utilitário instalado. Os usuário de outras versões do Windows deverão baixá-lo a partir do site da Microsoft, nos seguintes links:
· Windows Installer v1.10 para Windows NT 4.0
· Windows Installer v1.10 para Windows 95 e 98
Após ter instalado o utilitário Microsoft Windows Installer, clique duas vezes no arquivo de instalação do Apache. Uma tela como esta deverá aparecer:
Prossiga clicando no botão "Next", aceitando os termos da licença de uso e, na tela de Informações do Servidor ("Server Information"), onde é solicitado "Network Domain", "Server Name" e "Administrator's Email Address", informe, respectivamente: "localdomain", "localhost" e o seu endereço de e-mail. Deixe também selecionado a opção "Run as a service for All users", como indicado abaixo:
Prossiga selecionando a instalação completa ("Complete") e finalize a instalação.
O que é?
O Servidor Apache é o mais bem sucedido servidor web livre. Foi criado em 1995 por Rob McCool, então funcionário do NCSA (National Center for Supercomputing Applications). Numa pesquisa realizada em dezembro de 2007, foi constatado que a utilização do Apache representa 47.20% dos servidores ativos no mundo.
Apache e suas Funcionalidades:
O servidor é compatível com o protocolo HTTP versão 1.1. Suas funcionalidades são mantidas através de uma estrutura de módulos, podendo inclusive o usuário escrever seus próprios módulos — utilizando a API do software. Para garantir segurança nas transações HTTP, o servidor dispõe de um módulo chamado mod_ssl, o qual adiciona a capacidade do servidor atender requisições utilizando o protocolo HTTPS. Este protocolo utiliza uma camada SSL para criptografar todos os dados transferidos entre o cliente e o servidor, provendo maior grau de segurança, confidencialidade e confiabilidade dos dados. A camada SSL é compatível com certificados X.509, que são os certificados digitais fornecidos e assinados por grandes entidades certificadoras no mundo.
O servidor é configurado por um arquivo mestre nomeado httpd.conf e opcionalmente podem haver configurações para cada diretório utilizando arquivos com o nome .htaccess, onde é possível utilizar autenticação de usuário pelo próprio protocolo HTTP utilizando uma combinação de arquivo .htaccess com um arquivo .htpasswd, que guardará os usuários e senhas (criptografadas).
Sistemas:
É disponibilizado em versões para os sistemas Windows, Novell Netware, OS/2 e diversos outros do padrão POSIX (Unix, Linux, FreeBSD, etc)
