Upload
luciano-ribeiro
View
133
Download
6
Tags:
Embed Size (px)
Citation preview
Instituto Federal de Ciência e Tecnologia do Tocantins
Campus Araguatins
CONFIGURANDO O PROXY SQUID
PROFESSOR: VILSON SOARES DE SIQUEIRA
DISCIPLINA: REDES II
2
Sumário 1. INSTALANDO E CONFIGURANDO O SQUID ................................................................................... 3
1.1 CONSIDERAÇÕES ........................................................................................................................ 3
1.2 CONCEITOS DE SERVIDORES PROXY .......................................................................................... 3
1.3 PROXY CACHING ........................................................................................................................ 3
1.4 NAT - TRADUÇÃO DE ENDEREÇOS DE REDE. ............................................................................. 4
1.5 DIFERENÇA ENTRE UM FILTRO DE PACOTES E UM SERVIDOR PROXY ...................................... 5
1.6 O SQUID ..................................................................................................................................... 6
1.7 REQUISITOS DE SISTEMA ESPECÍFICOS PARA O PROXY CACHING ............................................. 7
2. INSTALANDO O SQUID .................................................................................................................. 7
2.1 DEBIAN/UBUNTU ....................................................................................................................... 7
2.2 CONFIGURANDO O SQUID ......................................................................................................... 8
2.3 CACHE ........................................................................................................................................ 9
2.4 CONTROLE DE ACESSO ............................................................................................................. 10
2.5. ANEXO: ARQUIVO DE CONFIGURAÇÃO DO SQUID ................................................................. 14
3
1. INSTALANDO E CONFIGURANDO O SQUID
1.1 CONSIDERAÇÕES
Os testes para configuração e utilização foram realizados utilizando a distribuição
Debian Squeeze (versão 6.0);
1.2 CONCEITOS DE SERVIDORES PROXY
O objetivo principal de um servidor proxy é possibilitar que máquinas de uma rede privada
possam acessar uma rede pública, como a Internet, sem que para isto tenham uma ligação
direta com esta. O servidor proxy costuma ser instalado em uma máquina que tenha acesso
direto à Internet, sendo que as demais efetuam as solicitações através desta. Justamente por
isto este tipo de servidor é chamado de proxy, pois é um procurador, ou seja, sistema que
faz solicitações em nome dos outros.
Um servidor proxy para o protocolo http, por exemplo, pode ter outras funcionalidades
implementadas. Visto que todas as solicitações de páginas efetuadas pelas máquinas da rede
privada serão feitas através dele, é muito útil armazenar localmente as páginas que foram
solicitadas, permitindo que os próximos acessos, efetuados por quaisquer máquinas da rede,
possam ser otimizados. Este conceito é chamado de caching, e vários servidores proxy na
verdade são servidores proxy cache. Pelo mesmo motivo, também é possível implementar
uma funcionalidade que permita controlar o que os clientes podem acessar e em que
momento. Um servidor proxy também pode implementar o NAT (Network Address
Translation – Tradução de Endereços de Rede). O NAT é tecnicamente a função de um
portal de nível de rede, mas alguns fornecedores também incluem este recurso em seus
produtos e servidores proxy.
1.3 PROXY CACHING
Os servidores de proxy cache são implementados na camada de aplicativo e processam
protocolos Internet específicos, tais como http e FTP. São definidas regras no servidor proxy
para determinar como um pedido de estação de trabalho deve ser processado.
Uma das principais tarefas de um servidor proxy cache é armazenar temporariamente
páginas da Web e arquivos de FTP para clientes proxy. Esses tipos de servidores proxy são
chamados de servidores de cache proxy. O cache aumenta o desempenho da rede ao reduzir
a quantidade de dados que são transferidos de fora da rede local.
Para implementar o proxy caching, cada estação de trabalho da rede é configurada como um
cliente proxy para um determinado serviço. Por exemplo, um cliente proxy Web iria
configurar seu navegador (browser) para reconhecer o servidor proxy. Quando um cliente
fizer um pedido no navegador para baixar uma certa página, o navegador fará o pedido ao
servidor proxy. O servidor proxy contém armazenadas as páginas visitadas recentemente.
Este cache contém as páginas Web que as estações de trabalho em toda a rede baixaram
recentemente.
4
O servidor proxy verifica o seu cache para ver se a página está disponível. Se a página
estiver disponível no cache será enviada ao cliente a página armazenada. Se a página não
estiver no cache, o servidor proxy baixará do site em questão, armazenará essa página no seu
cache e a enviará à estação de trabalho.
Para garantir que as páginas no cache não estejam desatualizadas, os dados do cache proxy
expiram após um tempo pré-determinado. No squid, esta configuração é chamada de tempo
de renovação de objeto (som, vídeo, arquivos texto, etc... ).
Este processo aumenta o desempenho da rede porque a página é baixada imediatamente para
o cliente a partir do servidor proxy, evitando ter de baixá-la da Internet.
1.4 NAT - TRADUÇÃO DE ENDEREÇOS DE REDE.
Muitos servidores proxy são distribuídos com a função de NAT. O NAT permite que o
endereço de rede interno de uma empresa seja ocultado da Internet. A empresa é
representada na Internet como um endereço de IP não relacionado com os endereços de IP
internos.
Utilizando um servidor proxy, todo o tráfego de dentro da empresa destinado à Internet é
enviado para o servidor proxy. O proxy dá para cada pacote um outro endereço de IP antes
transmiti-lo pela Internet. Quando o pacote de resposta chega, o servidor proxy o envia ao
servidor apropriado da empresa que havia feito o pedido. Este procedimento protege os
endereços verdadeiros da rede interna da Internet, dificultando o ataque de um cracker ao
sistema, já que o endereço do sistema protegido não é conhecido e não fica diretamente
acessível a partir da Internet.
Navegador da estação de
trabalho
Servidor Proxy
Pedido de página de Internet
Tem um página de Internet no
cache ?
SIM Enviar página de internet para a estação de trabalho.
Carregar página de Internet do cache
NÃO
5
1.5 DIFERENÇA ENTRE UM FILTRO DE PACOTES E UM SERVIDOR PROXY
Os 2 serviços são colocados no perímetro da rede. Ambos funcionam como um
intermediário entre uma LAN e a Internet. Ambos possuem a capacidade de filtrar o tráfego
transmitido para dentro e para fora da rede. Ambos utilizam regras para determinar se certos
tipos de tráfego terão autorização para passar pelo servidor ou se serão descartados.
O que acontece é que o filtro de pacotes não penetra tão fundo no pacote como o servidor
proxy. O filtro de pacotes analisa o tráfego nas camadas de rede (camada 3) e de transporte
(camada 4) do modelo OSI. Por exemplo, um filtro de pacotes determinará se autoriza a
passagem de um endereço ou de uma certa faixa de endereços IP. Se a sua rede é atacada a
partir de uma faixa constante de endereços de IP, você pode criar uma regra para descartar
todos os pacotes que se originarem dessa faixa. Você pode filtrar o tráfego por serviço ou
número de porta (por exemplo), criando uma regra que descarte todo o tráfego direcionado a
certas portas de escuta, tais como FTP, rlogin e tráfego Telnet, ou dentro de uma faixa de
números de portas. Você pode filtrar pacotes ICMP por tipo ou código, o que permite
descartar somente certos tipos de tráfego ICMP. Isto ajuda na sua proteção contra ataques
comuns de denial-of-service distribuídos (DDOS). Como os filtros de pacotes trabalham
nessas camadas, são muitas vezes implementados em roteadores no perímetro da rede.
O servidor proxy é capaz de analisar pacotes na camada de aplicativo (camada 7). Isto
oferece uma flexibilidade muito maior, porque permite que o tráfego dentro de um serviço,
como o tráfego da porta 80 (http) possa ser filtrado. Como mencionado anteriormente, isto
permite que os servidores proxy analisem o tráfego http ou FTP, e determinem se deve ou
não passar. Se houver uma regra que impeça a passagem de qualquer endereço WEB que
contiver a palavra “sexo”, então qualquer pedido de URL http que contiver “sexo” será
descartado.
Ethernet da empresa
176.168.11.25
176.168.11.35 176.168.11.45
Servidor proxy com NAT
INTERNET
200.130.10.205 176.168.11.78
Todos os servidores da empresa são representados na na Internet pelo
servidor proxy 200.130.10.205
6
1.6 O SQUID
O servidor Squid Web Proxy Cache é gratuito e funciona em código aberto para Unix e
Linux. Ele permite que os administradores implementem um serviço de proxy caching para
Web, acrescentem controles de acesso (regras), e armazenem até mesmo consultas de DNS.
O Squid originou-se de um programa desenvolvido pelo projeto Harvest chamado cached
(Cache Daemon). A National Science Foundation (NSF) financia o desenvolvimento do
Squid através do National Laboratory of Network Research (NLANR).
O Squid é um Web proxy cache que atende à especificação HTTP 1.1. É utilizado somente
por clientes proxy, tais como navegadores Web que acessem à Internet utilizando HTTP,
Gopher e FTP. Além disso, ele não trabalha com a maioria dos protocolos Internet. Isto
significa que ele não pode ser utilizado com protocolos que suportem aplicativos como
vídeo-conferência, newsgroups, RealAudio, ou videogames como o Quake ou Counter
Strike. O principal motivo destas limitações é que o Squid não é compatível com programas
que utilizem UDP. O Squid usa o UDP somente para comunicação inter-cache.
Qualquer protocolo de cliente suportado pelo Squid deve ser enviado como um pedido de
proxy no formato HTTP. A maioria dos navegadores suporta esta função, portanto, os
protocolos FTP, HTTP, SSL (Secure Socket Layer), WAIS (Wide Area Information Server)
são suportados na maioria das redes que utilizam o Squid.
Os protocolos funcionarão se você os solicitar utilizando o seu navegador e se ele estiver
configurado como um cliente proxy para o servidor Web proxy cache.
O Squid também suporta protocolos internos e de administração. Tais protocolos são usados
entre os caches que puderem existir em outros no mesmo ou em outros servidores de proxy-
caching, ou para a administração de um proxy cache.
Internet Cache Protocol (ICP) – Consulta outros caches sobre um determinado objeto;
Cache Digest – Obtém um índice de objetos de outros caches;
HTTP – Obtém os objetos de outros caches;
Hypertext Caching Protocol (HTCP) – Está sendo incluído no Squid;
Ethernet da empresa
Workstation
Workstation Workstation
Cache do servidor de proxy web
INTERNET
Filtro de pacotes baseado em endereço de IP, faixa de endereço de IP e faixa e
número de porta TCP/UDP.
Tráfego de HTTP e FTP, outras URL’s e pesquisa DNS. Também filtros de URL’s
baseados em conteúdo.
7
Simple Network Management Protocol (SNMP) – Obtém informações sobre o proxy e as
envia a uma Network Management Station (NMS) para análise.
1.7 REQUISITOS DE SISTEMA ESPECÍFICOS PARA O PROXY CACHING
O Squid utiliza mais recursos de sistema do que outros aplicativos. Os dois principais
subsistemas de hardware que o Squid utiliza e deve ter um bom desempenho é o tempo de
busca aleatória e a quantidade de memória no sistema.
Tempo de busca aleatória em disco – Para um proxy cache, o tempo de busca aleatória
deve ser o mais baixo possível. O problema é que os sistemas operacionais procuram
aumentar a velocidade de acesso em disco utilizando vários métodos que geralmente
reduzem o desempenho do sistema;
Quantidade de memória do sistema – A memória RAM é extremamente importante para a
utilização de um proxy cache. O Squid mantém uma tabela na memória RAM sobre os seus
objetos. Se uma parte dessa tabela tiver que sofrer swapping, o desempenho do Squid será
bastante degradado. O Squid é um processo, então qualquer swapping tornará o programa
mais lento. Por exemplo, se você tiver 16 GB armazenados no cache, precisará de 96 MB
(aproximadamente) de RAM para o indíce de objetos.
Outros requisitos do sistema, como velocidade de CPU, não são tão importantes assim. A
velocidade do processador somente será notado durante o início do sistema (durante a
criação do indíce de objetos). Um sistema multiprocessado não constuma fazer diferença no
desempenho do proxy cache, pois o Squid contém uma pequena porção de código
encadeado.
2. INSTALANDO O SQUID
2.1 DEBIAN/UBUNTU
root@server:/home/vilson#
# apt-get install squid
Ubuntu
Após a instalação, altere o dono e grupo do arquivo "swap.state", senão irá encontrar
problemas mais para frente:
root@server:/home/vilson#
# chown proxy:proxy /var/spool/squid/swap.state
Fedora/CentOS
root@server:/home/vilson#
# yum install squid
8
Após a instalação, coloque o Squid para iniciar durante o boot:
root@server:/home/vilson#
# chkconfig squid on
Slackware
Baixe o pacote do Squid, suas dependências e instale:
http://repository.slacky.eu/slackware(...)/squid-3.0.stable18-i486-1sl.tgz
ftp://ftp.slackware-brasil.com.br/slackware(...)/d/gcc-4.2.4-i486-1.tgz
ftp://ftp.slackware-brasil.com.br/slackware(...)/d/gcc-g++-4.2.4-i486-1.tgz
root@server:/home/vilson#
# installpkg gcc-4.2.4-i486-1.tgz
# installpkg gcc-g++-4.2.4-i486-1.tgz
# installpkg squid-3.0.stable18-i486-1sl.tgz
Após a instalação, coloque o Squid para iniciar durante o boot:
root@server:/home/vilson#
# chmod +x /etc/rc.d/rc.squid
# ln -s /etc/rc.d/rc.squid /etc/rc.d/rc0.d/K05squid
# ln -s /etc/rc.d/rc.squid /etc/rc.d/rc1.d/K05squid
# ln -s /etc/rc.d/rc.squid /etc/rc.d/rc2.d/K05squid
# ln -s /etc/rc.d/rc.squid /etc/rc.d/rc6.d/K05squid
# ln -s /etc/rc.d/rc.squid /etc/rc.d/rc3.d/S95squid
# ln -s /etc/rc.d/rc.squid /etc/rc.d/rc4.d/S95squid
# ln -s /etc/rc.d/rc.squid /etc/rc.d/rc5.d/S95squid
2.2 CONFIGURANDO O SQUID
O arquivo de configuração do Squid se encontra no seguinte caminho:
Debian/Ubuntu: "/etc/squid/squid.conf"
Fedora/CentOS: "/etc/squid/squid.conf"
Slackware: "/etc/squid/squid.conf"
Para começar com a configuração do zero, renomeie o arquivo de configuração padrão, crie
um novo arquivo com o nome "squid.conf" e adicione as seguintes configurações:
http_port 3128
visible_hostname servidor
cache_mgr webmaster@localhost
9
http_port: determina a porta que será usada pelo servidor.
visible_hostname: defina o nome de exibição do servidor.
cache_mgr: defina o e-mail do administrador para receber mensagem em
casos graves.
Para definir o idioma das páginas de mensagem de erros em português brasileiro, adicione a
seguinte configuração:
Debian/Ubuntu
error_directory /usr/share/squid/errors/Portuguese
Fedora/CentOS
error_directory /usr/share/squid/errors/pt-br
Slackware
error_directory /usr/share/squid/errors/Portuguese
2.3 CACHE
O cache é onde fica armazenado os objetos (arquivos e páginas) quando acessa as páginas
ou baixar arquivos pela Internet. Ao invés de toda vez que um usuário for acessar um site e
ter que esperar baixar a página toda e os arquivos direto da hospedagem, o servidor verifica
se já existe no cache podendo baixar direto do servidor, melhorando o desempenho na
navegação.
Para configurar o cache no Squid, adicione as seguintes configurações:
hierarchy_stoplist cgi-bin ?
cache_mem 32 MB
maximum_object_size_in_memory 64 KB
maximum_object_size 100 MB
hierarchy_stoplist: defina palavras que se for encontradas na url, a página
irá ser carregada direto do cache.
cache_mem: defina a quantidade de memória que o servidor irá usar para o
cache.
maximum_object_size_in_memory: defina o tamanho máximo do objeto
que poderá ser armazenado na memória, senão será armazenado no disco
rígido.
maximum_object_size: defina o tamanho máximo do objeto que poderá ser
armazenado no disco rígido, senão será descartado o objeto.
Para especificar o diretório do cache, aonde será armazenado os objetos e atribuir 2GB de
espaço de armazenamento no cache, adicione a seguinte configuração:
Debian/Ubuntu
cache_dir ufs /var/spool/squid 2048 16 256
10
Fedora/CentOS
cache_dir ufs /var/spool/squid 2048 16 256
Slackware
cache_dir ufs /var/log/squid/cache 2048 16 256
Agora vamos definir o tempo de vida dos objetos no cache, para que sempre o Squid for
verificá-los, saber se é necessário atualizá-los ou não.
refresh_pattern ^ftp: 360 20% 10080
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320
1ª coluna: defina o tempo em minutos, em cada acesso, quando deve
verificar se houve modificação no objeto.
2ª coluna: defina a porcentagem mínima da modificação do objeto que deve
ter para ser atualizado.
3ª coluna: defina o tempo em minutos, quando deve efetuar uma atualização
mesmo não ter sido modificado.
Para especificar o caminho do Log de acesso do Squid e o caminho do Log do cache,
adicione a seguinte configuração:
Debian/Ubuntu
access_log /var/log/squid/access.log
cache_log /var/log/squid/cache.log
Fedora/CentOS
access_log /var/log/squid/access.log
cache_log /var/log/squid/cache.log
Slackware
access_log /var/log/squid/logs/access.log
cache_log /var/log/squid/logs/cache.log
2.4 CONTROLE DE ACESSO
A ACL ou Lista de Controle de Acesso, é onde define aonde pode acessar ou não pela
Internet. Uma coisa importante que deve saber é que o Squid interpreta as ACL's de cima
para baixo, então deve ficar atento quando for criar as regras.
Crie duas acl com o tipo src (IP de origem) e adicione o IP do servidor e o IP da rede:
acl localhost src 127.0.0.1/32
acl localnet src 192.168.0.0/24
11
Crie uma acl com o tipo proto (protocolo) e adicione o protocolo "cache_object":
acl manager proto cache_object
O protocolo "cache_object" é usado para obter informações sobre o estado do Squid.
É recomendável que permita apenas o servidor obter as informações do Squid, então
adicione a seguinte regra:
http_access allow manager localhost
http_access deny manager
Crie uma acl do tipo method (método de requisição) e adicione o método PURGE:
acl purge method PURGE
O método de requisição PURGE serve para limpar/excluir objetos armazenados no cache.
Para permitir que apenas o servidor possa exclua objetos, adicione a seguinte regra:
http_access allow purge localhost
http_access deny purge
Crie uma acl do tipo port (porta) e adicione as portas que serão liberadas:
acl Safe_ports port 21 70 80 210 280 443 488 563 591 631 777 873 901 1025-65535
Se quiser deixar mais organizado, ou seja, adicionar uma porta de cada vez para poder
comentar em cada linha a descrição do protocolo da porta que está sendo liberada, também
pode deixando assim:
acl Safe_ports port 21 # ftp
acl Safe_ports port 70 # gopher
acl Safe_ports port 80 # http
acl Safe_ports port 210 # wais
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 443 # https
acl Safe_ports port 488 # gss-http
acl Safe_ports port 563 # nntps
acl Safe_ports port 591 # filemaker
acl Safe_ports port 631 # cups
acl Safe_ports port 777 # multiling http
acl Safe_ports port 873 # rsync
acl Safe_ports port 901 # swat
acl Safe_ports port 1025-65535 # unregistered ports
12
Para bloquear o acesso em portas que não foram liberadas, adicione a seguinte regra:
http_access deny !Safe_ports
Crie uma acl do tipo method (método de requisição) e adicione o método CONNECT, que
permite fazer conexão direta:
acl connect method CONNECT
Crie uma acl do tipo port (porta) e adicione as portas dos protocolos com SSL que foram
adicionadas na acl "Safe_ports" e devem ser liberadas para conexão direta:
acl SSL_ports port 443 # https
acl SSL_ports port 563 # nntps
acl SSL_ports port 873 # rsync
Para bloquear o acesso em portas que não foram liberadas para conexão direta, adicione a
seguinte regra:
http_access deny connect !SSL_ports
Crie uma acl do tipo dstdomain (domínio de destino) e adicione um dóminio iniciando com
o ponto:
acl domains dstdomain .twitter.com
Se no caso for vários domínios de destino, define o caminho do arquivo que será adicionado
os domínios:
acl domains dstdomain "/etc/squid/domains"
Crie o arquivo que foi definido na acl e adicione os domínios de destino:
.twitter.com
.youtube.com
.vimeo.com
Para bloquear o acesso nos domínios de destino, adicione a seguinte regra:
http_access deny domains
Crie uma acl do tipo url_regex (expressão regular na url) e adicione uma expressão regular:
acl words url_regex jogo
13
A acl do tipo url_regex percorre url em busca de expressões regulares. A acl é case-
sensitive, se no caso estiver procurando a expressão "jogo" e tiver "Jogo", serão
consideradas diferentes.
Para adicionar várias expressões, define o caminho do arquivo que será adicionado as
expressões. E use a opção "-i" para tornar a acl em case-insensitive:
acl words url_regex -i "/etc/squid/words"
Crie o arquivo que foi definido na acl e adicione as expressões regulares:
jogo
blog
msn
Para bloquear o acesso em urls com as expressões regulares, adicione a seguinte regra:
http_access deny words
Criar uma acl do tipo urlpath_regex (expressão regulares no caminho da url) e define o
caminho do arquivo que será adicionado as expressões regulares:
acl extensions urlpath_regex -i "/etc/squid/extensions"
A acl do tipo urlpath_regex é semelhante a url_regex, só que é ignorado o domínio e
protocolo. Por exemplo, essa url "http://www.dominio.com.br/blog/invasao.html", irá fazer
a busca da expressão regular apenas nessa parte "/blog/invasao.html":
Crie o arquivo que foi definido na acl e adicione as expressões regulares:
\.bat($|\?|\&)
\.exe($|\?|\&)
\.scr($|\?|\&)
Para bloquear o acesso em urls path com expressões regulares, adicione a seguinte regra:
http_access deny extensions
Sem mais acl para criar, adicione a seguinte regra para permitir que apenas as máquinas da
rede e o servidor sejam liberados para acessar a Internet:
http_access allow localnet
http_access allow localhost
http_access deny all
14
Com as acl definidas, a sequência das regras deverão está na ordenação correta,
independente esteja a acl junto com a regra. O que importa é que esteja criada a acl antes de
definir a regra.
Aqui vai uma amostra de como deve está ordenado as regras:
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
http_access deny domains
http_access deny words
http_access deny extensions
http_access allow localnet
http_access allow localhost
http_access deny all
Debian/Ubuntu
Após ter terminado as configurações, reinicie o servidor Squid:
root@server:/home/vilson#
# /etc/init.d/squid restart
Fedora/CentOS
Após ter terminado as configurações, inicie o servidor Squid:
root@server:/home/vilson#
# service squid start
Slackware
Após ter terminado as configurações, inicie o servidor Squid:
root@server:/home/vilson#
# /etc/rc.d/rc.squid start
2.5. ANEXO: ARQUIVO DE CONFIGURAÇÃO DO SQUID
Renomeia o arquivo original do squid que é squid.conf para squid.conf.bck e crie um novo
arquivo com o none: squid.conf com os dados que estão abaixo:
15
Arquivo de configuração do SQUID( squid.conf) que está dentro da pasta
/etc/squid/squid.conf
#######CONFIGURAÇÕES INICIAIS ##############################
# porta padrão do squid - http_port 3128
http_port 3128
# Nome do servidor squid
visible_hostname server
# Diretório onde serão armazenados os erros
error_directory /usr/share/squid/errors/pt-br
# Armazenamento na memória RAM do servidor squid
cache_mem 64 mb
# Limite de tamanho máximo do objeto na RAM
maximum_object_size_in_memory 2 mb
# Menor arquivo armazenado em RAM
minimum_object_size 3 kb
# Limite para o início da exclusão do cache
cache_swap_low 90
cache_swap_high 95
# Diretório onde serão armazenadas as páginas web navagadas na rede
local
cache_dir ufs /var/spool/squid 5000 16 256
cache_access_log /cache/squid/access.log
##############INICIANDO AS ACL ############################
# Liberar ou negar acesso para todas as faixas de IP
acl all src 0.0.0.0/0.0.0.0
# Limitar acesso a somente o servidor squid em questão
acl localhost src 127.0.0.1/255.255.255.255
# Define a faixa de IP da rede local
acl redelocal src 192.168.3.0/24
############PERMITINDO E NEGANDO ACESSO NA ACL ############
http_access allow localhost
http_access allow redelocal
http_access deny all
done