Mod6 Firewall Proxy

SISTEMAS OPERACIONAIS ABERTOS
Prof. Ricardo Rodrigues Barcelar

http://www.ricardobarcelar.com.br
- Módulo 6 -
FIREWALL E PROXY
O LINUX é um sistema operacional em desenvolvimento contínuo desde 1992, e

atualmente é utilizado por diversas corporações, devido à sua reconhecida confiabilidade e
segurança. Grandes corporações, como IBM, Novell, RedHat, e outras investem maciçamente
no desenvolvimento deste sistema.
Devido à sua tradição e utilização em aparatos de segurança, várias ferramentas
relacionadas também foram desenvolvidas nos últimos anos, e encontram-se em estágio
avançado de estabilidade, tais como filtros TCP/IP, roteamento, proxy, servidores WEB e
outros.
Devido ao crescimento da Internet, hoje é fundamental que os computadores estejam
protegidos contra invasões para evitar grandes estragos nas empresas. Ameaças como as de
spam, vírus e hackers são mais comuns em redes de computadores, que sem um conhecimento
adequado é praticamente impossível eliminá-las. Além disso, o controle de acesso dos usuários
é imprescindível para aumentar a produtividade e garantir o uso adequado do equipamento.
O servidor proxy (cache) de acesso à páginas da web e download de arquivos, é
responsável pela proteção de rede privada de acessos indevidos aos servidores e estações. É
utilizado para controle através de autenticação dos usuários, com registro dos acessos,
possibilitando extrair relatórios gerenciais sobre o uso da Internet pelos usuários.
Já o firewall, permite o controle do acesso externo a rede interna.
As vantagens de tais serviços são o acesso mais rápido a páginas da Internet e
economia da banda do link da empresa. Uma informação é lida através do servidor e
armazenada localmente no diretório de cache. Os acessos posteriores a esta informação serão
obtidos localmente. Com relação à segurança da rede, toda e qualquer tentativa de acesso à
rede privada é bloqueada, e estas tentativas são registradas.
Figura 1 - Esquema de proteção com Firewall e Proxy
1
1. SERVIDOR 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 é chamado de Proxy, pois é um procurador, ou seja, sistema que
faz solicitações em nome de outros.
Em outras palavras, o Proxy é um servidor que atende a requisições repassando os
dados do cliente à frente: um usuário (cliente) conecta-se a um servidor proxy, requisitando
algum serviço, como um arquivo, conexão, página web, ou outro recurso disponível em outro
servidor.
Um servidor proxy pode, opcionalmente, alterar a requisição do cliente ou a resposta do
servidor e, algumas vezes, pode disponibilizar este recurso mesmo sem se conectar ao servidor
especificado. Pode também atuar como um servidor que armazena dados em forma de cache
em redes de computadores. São instalados em máquinas com ligações tipicamente superiores
às dos clientes e com poder de armazenamento elevado.
Esses servidores têm uma série de usos, como filtrar conteúdo, providenciar anonimato,
entre outros.
Um proxy de cache HTTP ou em inglês caching proxy, permite por exemplo que o
cliente requisite um documento na World Wide Web e o proxy procura pelo documento no seu
cache. Se encontrado, a requisição é atendida e o documento é retornado imediatamente. Caso
contrário, o proxy busca o documento no servidor remoto, entrega-o ao cliente e salva uma
cópia no cache. Isto permite uma diminuição na latência, já que o servidor proxy, e não o
servidor original, é requisitado, proporcionando ainda uma redução do uso da banda.
O cache normalmente usa um algoritmo de expiração para remover documentos e
arquivos de acordo com a idade, tamanho e histórico de acessos (previamente programado).
Dois algoritmos simples são o Least Recently Used (LRU) e o Least Frequently Used (LFU). O
LRU remove os documentos que passaram mais tempo sem serem usados, enquanto o LFU
remove documentos menos frequentemente usados.
Normalmente um Proxy direciona as requisições para uma porta em específico. No
entanto para que este direcionamento fique transparente para o usuário é possível implementar
o chamado Proxy Transparente.
Um proxy transparente é um meio usado para obrigar os usuários de uma rede a
utilizarem o proxy. Além das características de cache dos proxies convencionais, estes podem
impor políticas de utilização ou recolher dados estatísticos, entre outras. A transparência é
conseguida interceptando o tráfego HTTP (por exemplo) e reencaminhando-o para um proxy
mediante a técnica do encaminhamento de portas, conhecida como port forwarding. Assim,
independentemente das configurações explícitas do utilizador, a sua utilização estará sempre
condicionada às políticas de utilização da rede. O RFC 3040 define este método como proxy
interceptador.
2
1.1. Squid Web Proxy
O Squid é um servidor proxy que suporta HTTP, HTTPS, FTP e outros. Ele reduz a
utilização da conexão e melhora os tempos de resposta fazendo cache de requisições
freqüentes de páginas web numa rede de computadores.
Ele suporta SSL, listas de acesso complexas e logging completo. Por utilizar o Internet
Cache Protocol, o Squid pode ser configurado para trabalhar de forma hierárquica ou mista
para melhor aproveitamento da banda.
O Squid consiste em um programa principal, squid, um sistema de busca e resolução de
nomes, dnsserver , e alguns programas adicionais para reescrever requests, fazer autenticação
e gerenciar ferramentas de clientes.
O Squid foi escrito originalmente para rodar em sistema operacional tipo Unix, mas ele
também funciona em sistemas Windows desde sua versão 2.6.STABLE4.
1.1.1. PROTOCOLOS UTILIZADOS - REDE E APLICAÇÃO
O Squid busca por comunicação TCP (Transmission Control Protocol) e ICP (Internet
Cache Protocol) em portas específicas. O TCP é usado para comunicação entre Web Servers e
clientes, e o ICP para conversa entre servidores de cache. Para cada servidor (ou cliente), a
configuração do Squid precisa fornecer uma única porta sobre a qual o Squid irá enviar as
requisições (TCP ou ICP) e ouvir as respostas.
Assim ele trabalha apenas com FTP, gopher e http. Existe uma confusão em achar que é
possível, através do Squid, configurar acesso a e-mails, ICQ, IRC, etc. Isso é totalmente
equivocado, visto que não faz sentido criar caches de e-mails pessoais, mensagens do ICQ, etc.
1.1.2. REQUISITOS
A maior parte das configurações depende apenas do Squid. Já o Proxy transparente

também depende do sistema operacional e do firewall. A instalação padrão do Squid, disponível
na maior parte das distribuições, não consegue lidar com o controle de banda, sendo necessário
recompilar o Squid.
1.1.3. INSTALAÇÃO
O Squid pode ser instalado em uma imensa variedade de sistemas operacionais.

Praticamente todos os sistemas Unix com um bom compilador C/C++ pode gerar binários do
Squid.
Os sistemas Linux derivados do Debian sempre prezaram pela facilidade de instalação
ou atualização de pacotes com seu sistema APT, que facilita muito a vida dos administradores.
Para instalar o squid basta executar o comando:
# apt-get install squid3
3
Fontes das versões mais atuais do Squid podem ser encontradas no site
http://www.squid-cache.org/Versions/
1.1.4. CONFIGURAÇÕES
a) Uma prática importante antes de começar as configurações é fazer uma cópia do

arquivo original de configurações do Squid ou então simplesmente renomear o arquivo e criar
um novo arquivo de configuração em branco.
# cd /etc/squid
# cp squid.conf squid.conf.original
b) Partindo da premissa que se optou pelo arquivo em branco, adicionar as seguintes

configurações no arquivo squid.conf:
http_port 3128
visible_hostname servidor
cache_mgr webmaster@localhost
http_port: determina a porta que será usada pelo servidor.

visible_hostname: define o nome de exibição do servidor.
cache_mgr: define o e-mail do administrador para receber mensagem em casos graves.
c) Para definir o idioma das páginas de mensagem de erros em português brasileiro,

adicione a seguinte configuração:
error_directory /usr/share/squid3/errors/Portuguese
1.1.4.1. Cache
a) Cache - O cache é onde ficam armazenados os objetos (arquivos e páginas) quando

se acessa as páginas ou se baixam arquivos pela Internet. Ao invés de toda vez que um usuário
for acessar um site 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 é necessário adicionar 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: define palavras que se forem encontradas na URL, a página irá ser
carregada direto do cache.
4
cache_mem: define a quantidade de memória que o servidor irá usar para o cache.
maximum_object_size_in_memory: define o tamanho máximo do objeto que poderá ser
armazenado na memória, senão será armazenado no disco rígido.
maximum_object_size: define o tamanho máximo do objeto que poderá ser armazenado
no disco rígido, senão o objeto será descartado.
b) Para especificar o diretório de cache, onde serão armazenados os objetos e atribuir

1GB de espaço de armazenamento, adicionar a seguinte configuração:
cache_dir ufs /var/spool/squid3 1024 16 256
Isto significa que será criada uma estrutura com 1024MB, 16 diretórios e 256
subdiretórios.
c) Para definir o tempo de vida dos objetos no cache, para que quando o Squid for
verificá-los, saber se é necessário atualizá-los ou não, adicionar a seguinte configuraçã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.
d) Por medida de segurança é importante não permitir que seja feito cache de páginas
seguras:
no_cache deny SSL_ports
e) Atendendo a norma de segurança NBR ISO/IEC 17799, recomenda-se que sejam

gerados registros de atividades dos usuários e que os mesmos sejam mantidos por tempo
definido dentro da corporação, possibilitando investigações futuras, bem como a monitoração
do controle de acesso. Para especificar o caminho do Log de acesso do Squid e o caminho do
Log do cache, adicionar a seguinte configuração:
access_log /var/log/squid3/access.log
cache_log /var/log/squid3/cache.log
5
1.1.4.2. Controle de Acesso/Filtro de conteúdo com ACL’s
Um recurso motivador para o uso de um web-proxy é o conceito de filtro de conteúdo,

que possibilita a filtragem do conteúdo web dos usuários.
Na ACL ou Lista de Controle de Acesso, é onde são definidas as permissões de acesso à
Internet. As seguintes ACL’s podem ser criadas:
- src: Filtro por rede ou endereço IP

- time: Filtro por hora e dia da semana
- urlpath_regex: Filtro de complemento de URL
- url_regex: Filtro de uma string na URL
- dstdomain: Filtro de uma URI
- proxy_auth: Filtro por usuários autenticados
- arp: Filtro por MAC Address
- maxconn: filtro por conexões
- proto: Filtro por protocolos
- port: Filtro por porta
As ACL’s são listas que fazem o agrupamento dos objetos que serão negados ou
liberados de acordo com as regras determinadas pelo administrador.
Sintaxe:
acl nome_da_acl tipo tipo_de_agrupamento
Exemplo:
acl almoco time 12:00-14:00
1.1.4.3. Permissionamento das ACS’s
Para uma rede corporativa é necessários definir o que é ou não permitido acessar. Para
tanto o Squid define um poderoso mecanismo para atribuir permissões aos acessos baseados
nas ACS’s criadas.
Sintaxe:
http_access allow|deny nome_da_acl
Exemplo:
acl maq1 src 10.0.0.1
acl diurno time 08:00-18:00
acl almoco time 12:00-14:00
6
http_access deny all

http_access allow maq1 diurno
http_access allow maq2 diurno
http_access allow maq2 almoco
http_access allow maq3 almoco
É importante lembrar que o principio básico de funcionamento é que o Squid faz a

leitura do arquivo squid.conf de cima para baixo. Sendo assim imagine que tivéssemos as
seguintes ACL’s e suas respectivas regras:
acl diretoria src "/etc/squid/diretoria "

acl usuarios src "/etc/squid/usuarios"
acl sites_bloqueados url_regex -i "/etc/squid/sites_bloqueados"
http_access allow diretoria

http_access deny sites_bloqueados
http_access allow usuarios
Isso significa que quando liberamos por primeiro a ACL “diretoria”, essa ACL terá acesso
total mesmo tendo abaixo uma ACL bloqueando sites. Já a ACL “usuários” não conseguirá
acessar os sites contidos na ACL “sites_bloqueados”, porque o bloqueio vem primeiro.
Vamos supor que precisamos bloquear uma palavra que esteja no meio de outra, como
por exemplo, deputados, a qual contém uma string não permitida.
Uma maneira de trabalhar com essa situação é criando duas listas de palavras: uma
com as palavras permitidas e outra com as palavras não permitidas:
- lista_negra
- lista_branca
A configuração ficaria, então, da seguinte forma:
acl lista_negra url_regex –i “/etc/squid/lista_negra”

acl lista_branca url_regex –i “/etc/squid/lista_branca”
Observação:
A url_regex trata a string dentro de uma URL completa. Por exemplo, se dentro do
arquivo lista_negra conter a palavra boy e qualquer parte da URL contiver a palavra boy, como
http://www.playboy.com.br o acesso será bloqueado.
O parâmetro –i diz que qualquer palavra dentro do arquivo sofrerá tratamento de case
sensitive.
O permissionamento ficará como a seguir:
http_access allow whitelist

http_access deny blacklist
7
Para construção do servidor Proxy serão aplicadas as seguintes ACL’s e seus respectivos
permissionamentos:
a) Criar 2 (duas) ACL’s com o tipo SRC (IP de origem) e adicionar o IP do servidor e o IP
da rede:
acl localhost src 127.0.0.1/32

acl rede_local src 10.0.0.0/8
b) 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.
c) É 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
d) 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.
d) Para permitir que apenas o servidor possa exclua objetos, adicione a seguinte regra:
http_access allow purge localhost

http_access deny purge
e) 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
f) Para bloquear o acesso em portas que não foram liberadas, adicione a seguinte regra:
http_access deny !Safe_ports
O sinal de “!” significa negação. No caso acima, serão negadas todas as portas
diferentes das listadas na ACL Safe_ports
8
g) 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
h) 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
i) 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
j) Crie uma ACL do tipo dstdomain (domínio de destino) e adicione um domínio iniciando
com o ponto:
acl domains dstdomain .twitter.com
k) Se no caso forem vários domínios de destino, definir o caminho do arquivo que serão
adicionados os domínios:
acl domains dstdomain "/etc/squid/dominios"
Para tanto é necessário criar o arquivo domínios como definido na ACL. Para tanto, crie
o arquivo usando o seguinte comando
# nano /etc/squid/dominios
E adicione os seguintes domínios para teste:
.twitter.com
.youtube.com
.vimeo.com
l) Para bloquear o acesso nos domínios de destino, adicione a seguinte regra:
http_access deny dominios
m) Crie uma ACL do tipo url_regex (expressão regular na URL) e adicione uma
expressão regular:
9
acl palavras url_regex sexo
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 "sexo" e tiver "Sexo", serão consideradas
diferentes.
n) Para adicionar várias expressões, definir o caminho do arquivo que serão adicionadas
às expressões. Usar a opção "-i" para tornar a ACL em case-insensitive:
acl palavras url_regex -i "/etc/squid/palavras"
Crie o arquivo "/etc/squid/palavras" como definido na ACL e adicione as expressões

regulares:
jogo
blog
msn
o) Para bloquear o acesso em URL’s com as expressões regulares, adicione a seguinte

regra:
http_access deny palavras
p) Criar uma ACL do tipo urlpath_regex (expressão regulares no caminho da url) e

definir o caminho do arquivo que será adicionado às expressões regulares:
acl extensions urlpath_regex -i "/etc/squid/extensoes"
A ACL do tipo urlpath_regex é semelhante a url_regex, só que é ignorado o domínio e

protocolo. Por exemplo, a 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 "/etc/squid/extensoes" como definido na ACL e adicione as
expressões regulares:
# nano /etc/squid/extensoes
Adicione as seguintes linhas:
\.bat($|\?|\&)
\.exe($|\?|\&)
\.scr($|\?|\&)
q) Para bloquear o acesso em URL’s path com expressões regulares, adicione a seguinte
regra:
10
http_access deny extensoes
r) 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 rede_local

http_access allow localhost
s) Com as ACL definidas, a sequência das regras deverá estar na ordenação correta,
independente da ACL ser criada junto com a regra. É importante que a ACL seja criada antes de
definir a regra.
Aqui vai uma amostra de como deve está ordenado às 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 dominios
http_access deny words
http_access deny extensoes
http_access allow rede_local
http_access allow localhost
1.1.4.4. Procedimentos Finais
a) Recarregar as configurações do Squid:
# /etc/init.d/squid3 reload
ou
# /etc/init.d/squid3 stop
# /etc/init.d/squid3 start
b) Configurar o navegador para acessar web via Proxy, apontando para o endereço do
servidor Proxy pela porta 3128.
1.1.5. Material complementar
Referência completa do Squid pode ser encontrada no site oficial:
11
2. FIREWALL
Firewall é o nome dado ao dispositivo de uma rede de computadores que tem por
objetivo aplicar uma política de segurança a um determinado ponto de controle da rede. Sua
função consiste em regular o tráfego de dados entre redes distintas e impedir a transmissão
e/ou recepção de acessos nocivos ou não autorizados de uma rede para outra. Este conceito
inclui os equipamentos de filtros de pacotes e de proxy de aplicações, comumente associados a
redes TCP/IP.
Figura 2 - Firewall na rede
Os primeiros sistemas firewall nasceram exclusivamente para suportar segurança no

conjunto de protocolos TCP/IP. O termo inglês firewall faz alusão comparativa da função que
este desempenha para evitar o alastramento de acessos nocivos dentro de uma rede de
computadores à uma parede corta-fogo (firewall), que evita o alastramento de incêndios pelos
cômodos de uma edificação.
Existe na forma de software e hardware, ou na combinação de ambos (neste caso,
normalmente é chamado de "appliance").
A complexidade de instalação depende do tamanho da rede, da política de segurança,
da quantidade de regras que autorizam o fluxo de entrada e saída de informações e do grau de
segurança desejado.
Existem basicamente dois tipos de firewalls:
a) Nível de Aplicação - Este tipo de firewall analisam o conteúdo do pacote para tomar
suas decisões de filtragem. Firewalls deste tipo são mais intrusivos (pois analisam o conteúdo
de tudo que passa por ele) e permitem um controle relacionado com o conteúdo do tráfego.
Alguns firewalls em nível de aplicação combinam recursos básicos existentes em firewalls em
nível de pacotes combinando as funcionalidade de controle de tráfego/controle de acesso em
uma só ferramenta. Servidores proxy, como o Squid, são um exemplo deste tipo de firewall.
b) Nível de Pacotes - Este tipo de firewall toma as decisões baseadas nos parâmetros do
pacote, como porta/endereço de origem/destino, estado da conexão, e outros parâmetros do
12
pacote. O firewall então pode negar o pacote (DROP) ou deixar o pacote passar (ACCEPT). O
iptables é um excelente firewall que se encaixa nesta categoria.
Os dois tipos de firewalls podem ser usados em conjunto para fornecer uma camada
dupla de segurança no acesso as suas máquinas/máquinas clientes.
2.1. Tipo de Proteção
O firewall vem com a finalidade de oferecer proteção a serviços que devem ter acesso
garantido a usuários externos e serviços os quais serão bloqueados a todas/determinadas
máquinas.
É recomendável bloquear o acesso a todas as portas menores que 1024 por executarem
serviços que rodam com privilégio de usuário root, e autorizar somente o acesso as portas que
realmente deseja (configuração restritiva nesta faixa de portas).
É também função do firewall analisar que tipo de conexões podem passar e quais
bloquear. Serviços com autenticação em texto plano e potencialmente inseguros como rlogin,
telnet, ftp, NFS, DNS, LDAP, SMTP RCP, X-Window são serviços que devem ser ter acesso
garantido somente para máquinas/redes que você confia. Estes serviços podem não ser só
usados para tentativa de acesso ao seu sistema, mas também como forma de atacar outras
pessoas aproveitando-se de problemas de configuração.
Outra tarefa do firewall é analisar e controlar quais máquinas terão acesso livre e quais
serão restritas:
- Que serviços deverão ter prioridade no processamento.
- Que máquinas/redes nunca deverão ter acesso a certas/todas máquinas.
- O volume de tráfego que o servidor manipulará. Através disso é possível balancear o
tráfego entre outras máquinas, configurar proteções contra DoS, syn flood, etc.
- O que tem permissão de passar de uma rede para outra (em máquinas que atuam
como roteadores/gateways de uma rede interna).
A análise destes pontos pode determinar a complexidade do firewall, custos de

implementação, prazo de desenvolvimento e tempo de maturidade do código para
implementação. Existem muitos outros pontos que podem entrar na questão de
desenvolvimento de um sistema de firewall, eles dependem do tipo de firewall que está
desenvolvendo e das políticas de segurança de sua rede.
Existem três grandes grupos que fazem as funções de firewall:
- Físicos
- Filtros de pacotes
- Firewall de aplicação
Como firewall físico podemos citar roteadores que comutam protocolos, portanto,
fazem o vinculo entre duas redes podendo ser elas diferente uma de outra.
Para fazer o roteamento, o micro roteador deve possuir uma placa de rede em cada
sub-rede. Também é necessário informar em cada máquina quem será o micro responsável
pelo roteamento. O nome técnico desse micro é gateway.
13
Figura 3 – Gateway
Como firewall por pacotes refere-se ao que se restringe a trabalhar nas camadas
TCP/IP, decidindo quais pacotes de dados podem passar e quais não. Tais escolhas são regras
baseadas nas informações endereço IP remoto, endereço IP do destinatário, além da porta TCP
usada. Quando devidamente configurado, esse tipo de firewall permite que somente
"computadores conhecidos troquem determinadas informações entre si e tenham acesso a
determinados recursos". Um firewall assim, também é capaz de analisar informações sobre a
conexão e notar alterações suspeitas, além de ter a capacidade de analisar o conteúdo dos
pacotes, o que permite um controle ainda maior do que pode ou não ser acessível.
Firewalls de controle de aplicação (exemplos de aplicação: SMTP, FTP, HTTP, etc)

são instalados geralmente em computadores servidores e são conhecidos como proxy. Este tipo
não permite a comunicação direta entre a rede e a Internet. Tudo deve passar pelo firewall,
que atua como um intermediador. O proxy efetua a comunicação entre ambos os lados por
meio da avaliação do número da sessão TCP dos pacotes.
Em linux, até a versão de kernel 2.2.x o firewall embutido era o IPChains. Em Versões
de kernel maiores foi substituído pelo IPTables.
Tanto um como outro trata endereços de IP, Serviços e portas com relação ao que deve
ser “trancado” e ao que pode ser liberado.
2.2. IPTABLES
No kernel do Linux 2.4, foi introduzido o firewall iptables (também chamado de netfilter)
que substitui o ipchains dos kernels da série 2.2. Este firewall tem como vantagem ser muito
estável (assim como o ipchains e ipfwadm), confiável, permitir muita flexibilidade na
programação de regras pelo administrador do sistema, mais opções disponíveis ao
administrador para controle de tráfego, controle independente do tráfego da rede local/entre
redes/interfaces devido à nova organização das etapas de roteamento de pacotes.
O iptables é um firewall em nível de pacotes e funciona baseado no endereço/porta de
origem/destino do pacote, prioridade, etc. Funciona através da comparação de regras para
14
saber se um pacote tem ou não permissão para passar. Em firewalls mais restritivos, o pacote é
bloqueado e registrado para que o administrador do sistema tenha conhecimento sobre o que
está acontecendo em seu sistema.
Ele também pode ser usado para modificar e monitorar o tráfego da rede, fazer NAT
(masquerading, source nat, destination nat), redirecionamento de pacotes, marcação de
pacotes, modificar a prioridade de pacotes que chegam/saem do seu sistema, contagem de
bytes, dividir tráfego entre máquinas, criar proteções anti-spoofing, contra syn flood, DoS, etc.
O tráfego vindo de máquinas desconhecidas da rede pode também ser bloqueado/registrado
através do uso de simples regras. As possibilidades oferecidas pelos recursos de filtragem
iptables como todas as ferramentas UNIX maduras dependem de sua imaginação, pois ele
garante uma grande flexibilidade na manipulação das regras de acesso ao sistema, precisando
apenas conhecer quais interfaces o sistema possui, o que deseja bloquear, o que tem acesso
garantido, quais serviços devem estar acessíveis para cada rede, e iniciar a construção de seu
firewall.
O iptables ainda tem a vantagem de ser modularizável, funções podem ser adicionadas
ao firewall ampliando as possibilidades oferecidas.
Um firewall não funciona de forma automática (instalando e esperar que ele faça as
coisas automaticamente), é necessário pelo menos conhecimentos básicos de rede TCP/IP,
roteamento e portas para criar as regras que farão a segurança de seu sistema. A segurança do
sistema depende do controle das regras que serão criadas.
2.2.1. INSTALAÇÃO
Em sistemas Linux derivados do Debian a instalação pode ser feita pelo comando apt-
get, como se segue:
# apt-get install iptables
É importante lembrar que é necessário que o kernel tenha sido compilado com suporte
ao iptables. O requerimento mínimo de memória necessária para a execução do iptables é o
mesmo do kernel 2.4 (4MB). Dependendo do tráfego que será manipulado pela(s) interface(s)
do firewall ele poderá ser executado com folga em uma máquina 386 SX com 4MB de RAM.
Como as configurações residem no kernel não é necessário espaço extra em disco
rígido para a execução deste utilitário.
Para certificar-se que o iptables está instalado execute o seguinte comando:
# modprobe iptables
O pacote iptables contém o utilitário iptables (e ip6tables para redes ipv6) necessários
para inserir as regras no kernel.
2.2.2. PACOTES IPTABLES
- iptables - Sistema de controle principal para protocolos ipv4
15
- ip6tables - Sistema de controle principal para protocolos ipv6

- iptables-save - Salva as regras atuais em um arquivo especificado como argumento.
Este utilitário pode ser dispensado por um shell script contendo as regras executado na
inicialização da máquina.
- iptables-restore - Restaura regras salvas pelo utilitário iptables-save.
2.2.3. REGRAS
As regras no iptables são como comandos passados para que ele realize uma
determinada ação (como bloquear ou deixar passar um pacote) de acordo com o
endereço/porta de origem/destino, interface de origem/destino, etc. As regras são armazenadas
dentro dos chains e processadas na ordem que são inseridas.
As regras são armazenadas no kernel, o que significa que quando o computador for
reiniciado tudo o que fez será perdido. Por este motivo elas deverão ser gravadas em um
arquivo para serem carregadas a cada inicialização.
Exemplo:
iptables -A INPUT -s 123.123.123.1 -j DROP.
2.2.4. CHAINS
Os Chains são locais onde as regras do firewall definidas pelo usuário são armazenadas
para operação do firewall. Existem dois tipos de chains:
- Os embutidos (como os chains INPUT, OUTPUT eFORWARD)
- Os criados pelo usuário.
Os nomes dos chains embutidos devem ser especificados sempre em maiúsculas (note
que os nomes dos chains são case-sensitive, ou seja, o chain input é completamente diferente
de INPUT).
2.2.5. TABELAS
Tabelas são os locais usados para armazenar os chains e conjunto de regras com uma
determinada característica em comum. As tabelas podem ser referenciadas com a opção -t
tabela e existem três tabelas disponíveis no iptables:
2.2.5.1. Filter
Esta é a tabela padrão, contém três chains padrões:

- INPUT: Consultado para dados que chegam a máquina
- OUTPUT: Consultado para dados que saem da máquina
- FORWARD: Consultado para dados que são redirecionados para outra interface de
rede ou outra máquina.
16
Os chains INPUT e OUTPUT somente são atravessados por conexões indo/se originando
de localhost.
Observação:
Para conexões locais, somente os chains INPUT e OUTPUT são consultados na tabela
filter.
2.2.5.2. Nat
Usada para dados que gera outra conexão (masquerading, source nat, destination nat,
port forwarding, proxy transparente são alguns exemplos).
Possui três chains padrões:
- PREROUTING: Consultado quando os pacotes precisam ser modificados logo que
chegam. É o chain ideal para realização de DNAT e redirecionamento de portas.
- OUTPUT : Consultado quando os pacotes gerados localmente precisam ser modificados
antes de serem roteados. Este chain somente é consultado para conexões que se originam de
IPs de interfaces locais.
- POSTROUTING: Consultado quando os pacotes precisam ser modificados após o
tratamento de roteamento. É o chain ideal para realização de SNAT e IP Masquerading.
2.2.5.3. Mangle
Utilizada para alterações especiais de pacotes (como modificar o tipo de serviço (TOS)
ou outros detalhes que serão explicados a frente.
Possui dois chains padrões:
- INPUT: Consultado quando os pacotes precisam ser modificados antes de serem
enviados para o chain INPUT da tabela filter.
- FORWARD: Consultado quando os pacotes precisam ser modificados antes de serem
enviados para o chain FORWARD da tabela filter.
- PREROUTING: Consultado quando os pacotes precisam ser modificados antes de ser
enviados para o chain PREROUTING da tabela nat.
- POSTROUTING: Consultado quando os pacotes precisam ser modificados antes de
serem enviados para o chain POSTROUTING da tabela nat.
- OUTPUT: Consultado quando os pacotes precisam ser modificados antes de serem
enviados para o chain OUTPUT da tabela nat.
2.2.6. CONFIGURAÇÃO
Com as regras a seguir será configurado um servidor básico para firewall.

a) Inicialmente é preciso verificar se o IPTables está instalado. Para isso execute o
seguinte comando:
#iptables –v
17
b) Criar um arquivo chamado firewall dentro do diretório /etc/init.d e dar a ele

permissão de execução:
#touch /etc/init.d/firewall (criação do arquivo)
#chmod +x /etc/init.d/firewall (dando permissão de execução)
#vi /etc/init.d/firewall(abrindo o arquivo para edição)
Para agilizar esta tarefa, o arquivo firewall pode ser baixado no link downloads do site.
Sendo assim, ignorar o primeiro e o último comando:
#cd /etc/init.d
#wget www.ricardobarcelar.com/arquivos/firewall
#chmod +x /etc/init.d/firewall (Permissão de execução)
Com estas simples configurações está instalado e configurado um firewall.
c) Em se tratando de um firewall é recomendável bloquear respostas ao comando ping,

mantendo o servidor escondido. Para isso, edite o arquivo /etc/sysct1.conf :
# vi /etc/sysct1.conf
E adicione as seguintes linhas:

net.ipv4.icmp_echo_ignore_all = 1
Em situações reais é recomendável instalar outros recursos que darão maior

flexibilidade, segurança e opções de administração para o responsável pela rede.
Dentre ela destaca-se:
Layer7
É um excelente plugin para o netfilter/iptables que trabalha na camada de aplicação,
dando maior flexibilidade ao firewall.
SARG
SARG - Squid Analysis Report Generator é uma ferramenta que permite ver o que o
usuário faz na Internet. Provê muitas informações sobre as atividades, tais como: tempos,
bytes trafegados, sites acessados, etc.
MRTG
O MRTG é um programa feito em perl muito útil para analisar o tráfego utilizado em sua
rede/link. Ele gera gráficos que te mostram o uso da banda em termos de velocidade.
Firewall Admin
Solução web que permite o gerenciamento do IPTables através de uma página web.
Pode ser obtido através do comando:
#cd /var/www
#wget http://ovh.dl.sourceforge.net/sourceforge/ firewalladmin/
firewalladmin-0.3.tar.gz
#chmod a+w config.php
18
Abrir um navegador web e digitar o endereço:

http://ip_do_servidor/firewall/
Muito cuidado com esta ferramenta, pois se configurada incorretamente permite o

acesso as configurações do firewall, através da Internet, por qualquer pessoa.
Existem outras ferramentas que podem ser implementadas, bem como outras
distribuições de firewall’s, como o Endian, por exemplo. No entanto optamos por utilizar as
ferramentas aqui demonstradas.
De igual forma, as configurações aqui descritas não são suficientes para implementação
comercial da solução. Tais configurações são somente para efeitos didáticos.
Outras configurações muito interessantes para aprendizado podem ser encontradas em:
http://wiki.ubuntu-br.org/ConfigurandoFirewall
http://wiki.ubuntu-br.org/Iptables
http://www.guiaubuntupt.org/wiki/index.php?title=Iptables#Iptables_How_to_B.C3.A1sico
REFERÊNCIAS
Básica
http://www.guiafoca.org/
http://www.squid-cache.org/
http://www.squid-cache.org.br/
Complementar
SILVA, Cesar Augustus - Instalando o Servidor Squid no Linux
http://www.linuxman.pro.br/squid/
UBUNTU Documentation
https://help.ubuntu.com/community/IptablesHowTo
19

Idioma

Mod6 Firewall Proxy

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Mod6 Firewall Proxy

Enviado por

Direitos autorais:

Formatos disponíveis

SISTEMAS OPERACIONAIS ABERTOS

Prof. Ricardo Rodrigues Barcelar

O LINUX é um sistema operacional em desenvolvimento contínuo desde 1992, e

Figura 1 - Esquema de proteção com Firewall e Proxy

O objetivo principal de um servidor proxy é possibilitar que máquinas de uma rede

1.1. Squid Web Proxy

1.1.1. PROTOCOLOS UTILIZADOS - REDE E APLICAÇÃO

A maior parte das configurações depende apenas do Squid. Já o Proxy transparente

O Squid pode ser instalado em uma imensa variedade de sistemas operacionais.

# apt-get install squid3

a) Uma prática importante antes de começar as configurações é fazer uma cópia do

b) Partindo da premissa que se optou pelo arquivo em branco, adicionar as seguintes

http_port: determina a porta que será usada pelo servidor.

c) Para definir o idioma das páginas de mensagem de erros em português brasileiro,

a) Cache - O cache é onde ficam armazenados os objetos (arquivos e páginas) quando

b) Para especificar o diretório de cache, onde serão armazenados os objetos e atribuir

cache_dir ufs /var/spool/squid3 1024 16 256

refresh_pattern ^ftp: 360 20% 10080

no_cache deny SSL_ports

e) Atendendo a norma de segurança NBR ISO/IEC 17799, recomenda-se que sejam

1.1.4.2. Controle de Acesso/Filtro de conteúdo com ACL’s

Um recurso motivador para o uso de um web-proxy é o conceito de filtro de conteúdo,

- src: Filtro por rede ou endereço IP

1.1.4.3. Permissionamento das ACS’s

http_access deny all

É importante lembrar que o principio básico de funcionamento é que o Squid faz a

acl diretoria src "/etc/squid/diretoria "

http_access allow diretoria

A configuração ficaria, então, da seguinte forma:

acl lista_negra url_regex –i “/etc/squid/lista_negra”

O permissionamento ficará como a seguir:

http_access allow whitelist

acl localhost src 127.0.0.1/32

acl manager proto cache_object

O protocolo "cache_object" é usado para obter informações sobre o estado do Squid.

c) É recomendável que permita apenas o servidor obter as informações do Squid, então

http_access allow manager localhost

acl purge method PURGE

O método de requisição PURGE serve para limpar/excluir objetos armazenados no

http_access allow purge localhost

http_access deny !Safe_ports

acl connect method CONNECT

acl SSL_ports port 443 # https

http_access deny connect !SSL_ports

acl domains dstdomain .twitter.com

acl domains dstdomain "/etc/squid/dominios"

E adicione os seguintes domínios para teste:

l) Para bloquear o acesso nos domínios de destino, adicione a seguinte regra:

http_access deny dominios

acl palavras url_regex sexo

acl palavras url_regex -i "/etc/squid/palavras"

Crie o arquivo "/etc/squid/palavras" como definido na ACL e adicione as expressões

o) Para bloquear o acesso em URL’s com as expressões regulares, adicione a seguinte

http_access deny palavras

p) Criar uma ACL do tipo urlpath_regex (expressão regulares no caminho da url) e

acl extensions urlpath_regex -i "/etc/squid/extensoes"

A ACL do tipo urlpath_regex é semelhante a url_regex, só que é ignorado o domínio e

Adicione as seguintes linhas:

http_access deny extensoes

http_access allow rede_local

http_access allow manager localhost

1.1.4.4. Procedimentos Finais

a) Recarregar as configurações do Squid: